OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] SML (was Elliotte Rusty Harold on Web Services)

[ Lists Home | Date Index | Thread Index ]

[Rick Jelliffe]

 >I don't think I have changed my position: I was not against SML as merely an
 >"effort to subset XML" but as an antagonistic, premature, dogma-driven 
 >in reductionism whose end result could only be to get rid of everything, as
 >in XML 2.0alpha.  And one that diverted peoples attention from the looming
 >XML Schemas: a real source of complication.[1]

Oh I dunno. My take is different in most respects (comments inline below):

 >I think there were five tendencies at work in SML that doomed it despite 
the talent
 >of those involved and their level of concern:

 >a naive view of where the costs of  parsing lies
This was never a concern in my case. Indeed I've written often about the 
of focusing on parsing speed 

 >, reductionism (the failure to value that a limited redundancy or sugar or
 >lubrication in a language increases its usefulness),
The verbosity of markup never really bothered me thought the interchangeability
of aspects of it (like the classic element/attribute divide) do fascinate me.

 >  a related belief that anything that can be layered should be layered
 > (ignoring the issue of how a document should declare
 > or specify this layering),

I'm guilty of that one I think. I've recently come to appreciate the 
pervasiveness of hermeneutic
circles in mainstream technologies. However, as a transformation 
decomposition freak
(i.e. the sadly under-attended xpipe) I strive to decompose complex 
processing into loosely
coupled data processing passes where possible.

This is a very different form of "layering" to the form normally found in the
(increasingly-known-to-be-flawed) stepwise refinement -> procedural 
approach to complexity management.

 >an Americanist tendency that if what is good for them will
 >have to be good enough for everyone else, and the lack of agreed 

Not applicable in my case:-)

 >Furthermore, the mental furniture of infoset versus syntax was not 
available at
 >that time.

As I've said before, the BIG problem with the infoset is that we are no 
nearer to establishing
a core mechanism of specifying what goes in and what comes out of an
XML processor.

We got caught up in conversations where we were taking passed each other. 
People on
this list have mutually incompatible interpretations of fundamental terms 
like "syntax" and
"data model"!

The brittle nature of any XML-in, XML-out specification makes it a fog of a 
problem to
join tools together.

We should have fixed it but we didn't. The catastrophic effect of that 
failure is that
the object-serializaton folk seized the opportunity to make the in/out 
spec. rigorous
using data typing.

A glorious opportunity has been lost in my opinion.

We got caught up in self-congratulation when XML took off.

Now it is becoming something else and I fear we markup heads have only
ourselves to blame.

Oh well...

But before I go let me say one more thing. EVERY XML app I've every seen
IS A SUBSET of XML. By that I mean that it is a trivial matter to create a 
XML 1.0 compliant document that causes the tool to choke. Be in not supporting
case sensitive element type names or not handling DOCTYPE declarations or
not resolving external  entities or supporting a teeny subset of Unicode or 
white space or ...And as for namespaces - don't get me started on namespaces!

Its interesting that in this industry we don't have a culture of 
plug-fests. We should because
the results would be surprising to a lot of people. Joining up XML tools is 
plain HARD.

The XML spec. leaves a lot unsaid about what goes in and what comes out. 
XML namespaces
makes the problems significantly more complex.

We hide behind "XML compliance" at parse time and fail to look at what 
comes out
of our "XML compliant" apps. Is it any wonder we cannot integrate these things




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS