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

["Simon St.Laurent" <simonstl@simonstl.com>]

G. Ken Holman wrote:
> At 2008-12-01 11:06 -0500, Simon St.Laurent wrote:
>> Michael Kay wrote:
>>> If all the inputs and outputs of the application are in XML, and if the
>>> processing is within the capabilities of those languages, then why 
>>> would you want to do anything else?
>>
>> Because I think this situation genuinely applies in about 5-10% of 
>> actual applications...
> 
> I disagree if by "actual applications" you mean "actual applications 
> acting on XML documents".

I think this may be the rub.  Most "applications acting on XML 
documents" were created by people who aren't actually interested in XML. 
  They use XML as a transfer mechanism, not a field with its own 
standards of excellence.

Even if those developers are using XML formats created by people who 
themselves understood how to create a decent XML format, their 
perspective and perhaps more importantly their business process is 
rarely XML-centric, or even document-centric.

After years of arguing that it should be XML-centric, I've concluded 
that it really only makes sense to establish an XML-centric beachhead in 
fields that are genuinely document-centric, and not try to tell people 
that they should select their tools based on what they see as a transfer 
format.

>> Please, certainly, promote your excellent tools for those applications 
>> - but let's not all get drunk on the prospect of XML data needing XML 
>> processing.
> 
> I'm not sure that is fair, especially given the level of excellence of 
> Mike's tools.  I didn't read his comment at all as boasting.

Mike's tools are genuinely excellent and worth promoting.  The 
drunkenness I'm concerned about originates in the original question 
Roger asked.  It feels to me like a grotesque and likely 
counter-productive overreach.

> Too many times in client situations I've delivered an end-to-end XML 
> solution to a problem they are having and at the 11th hour some Java 
> programmer on the team decides to "just replace this step with a simple 
> Java program so that I don't have to invoke an XML processor" and messes 
> things up.

If they're doing that inside an XML pipeline, yes, it can be a problem. 
  If you're telling them that they should be doing their data processing 
using XML tools instead of the Java environments they've already built 
and are familiar with, then again I'd ask if we aren't pushing too hard 
on the vast majority of programming people who don't worship at the 
altar of XML.

> The burden of handling XML issues such as character sets and 
> well-formedness moves to the programmer when not using XML-tools for 
> processing XML documents.

These are gateway issues - so long as your parser is set up right (yes, 
a tricky question), they don't have an impact on processing deeper 
inside the system.

> I see a pure XML tool approach to a problem being *safer* than a 
> mixed-technology approach to a problem.

I don't presently see that as true, if only because there aren't enough 
people who know how to maintain them properly.  I don't see a large and 
growing XSLT and XQuery developer market either.

> And given how well Mike's tools work, it makes delivering professional 
> results easy and for many aspects of XML processing bulletproof in ways 
> not provided for by using non-XML-native tools.
> 
> Unfortunately I cannot say that for all XML tools.  I exploit useful XML 
> and XSLT facilities that are not properly supported by many popular tools.

Another way of putting that is that the XML technology ecosystem isn't 
actually mature yet, even if Mike's tools are.

Which I'd say is more reason to be cautious about treating XML as the 
center of the processing universe.

Thanks,
Simon St.Laurent
Recently enjoying the humility of mere YAML
http://simonstl.com/