Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Feasibility of "do all application coding in the XML

From: "Steven J. DeRose" <sderose@---.--->
To: xml-dev@-----.---.---
Date: 12/1/2008 8:03:00 PM
At 7:25 PM +0100 12/1/08, James Fuller wrote:
>  > 2. Game programming :)
>
>I am not a gamer, but I have heard that world of warcraft is heavily
>doped up with XML

Perhaps not "heavily", but World of Warcraft does specify the GUI 
using XML, and players use it in combination with a scripting 
language called Lua, to write add-ons.


As to the original question, it seems to me useful to make a few 
finer distinctions (not to mention defining what counts as an "XML 
language" -- Perl has some libraries for XML -- does that make it an 
"XML language"? ). But I think a more important distinction is:

     *Can* you do all application programming in XML languages
versus
     *Should* you....

XSLT is probably the clearest example of an "XML" programming 
language. There are claimed proofs that XSLT is Turing-complete. If 
those proofs are correct, then you can write anything in XSLT that 
you can write in any other computer language: any "computable" 
function (where "computable" has a particular formal definition -- it 
remains an open question whether you can thereby compute anything the 
human brain can de facto compute, but that's the present question).

Whether it is *wise* to do so depends on many factors:

If your application primarily involves documents, it likely is, 
because there is considerable cost to moving from one language to 
another in the middle of a processing stream.

But if (for example) you're doing a graphics-intensive application 
such as gaming, rendering a fully-animated movie, or simulating 
astronomical phenomena, XSLT would IMHO be a poor choice, because:

     a) there are few/no tools and libraries that are well optimized 
for such purposes

     b) if there were such tools and libraries, they were almost 
certainly not written in XSLT themselves, so wouldn't that be using 
non-XML-based tools anyway?

The point is not whether a new XSLT tool could be written that *was* 
optimized for graphical rendering, artificial intelligence, kernel 
implementation, microprogramming, CNC machining, or some other 
relatively-non-XML-ish domain; of course it could. But such tools 
often don't exist, which means that you'd have to invest an awful lot 
to implement and maintain one (especially one as good as the non-XML 
programming tools that *do* exist and already have maintainers, 
testers, programmers, advocates, and teachers already out there).

In other words, at some point the cost of moving data from one format 
to another can be greatly exceeded by the cost of implementing all 
the stuff you'd need. I know of no inherent/deontic moral virtue to 
XML; its value is utilitarian. So if the value equation doesn't work 
out, then I would say you shouldn't use it.

However, I suspect that a more common real-world difficulty people on 
this list face is that customers sometimes reject XML- solutions 
based on a very short-term calculation involving inertia rather than 
real costs and benefits, ignoring major costs/problems that follow.


Steve

-- 

Steve DeRose -- http://www.derose.net, email sderose@a...


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent