[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> [hating myself for jumping into this permathread once again :-) ]
>
> On Fri, 21 Feb 2003 07:16:37 -0500, Elliotte Rusty Harold
> <elharo@metalab.unc.edu> wrote:
>
>> Sun's recently posted an alpha of J2ME Web Services
>> <http://jcp.org/aboutJava/communityprocess/review/jsr172/index.html>
>> This spec defines a subset of JAXP, SAX, and XML which is only
>> suitable for processing SOAP messages. ... Among other sins
>
>
> Anyone following sml-dev three years ago would not be surprised to hear
> that vendors are subsetting XML for mobile, data-oriented applications.
> Where's the "sin" here? What's a cellphone supposed to do with an
> external entity reference, or a notation declaration? Should well-known
> interoperability antipatterns such as default attribute values be
> encouraged in lightweight applications?
>
>>
>> I did not recognize any of the names in the expert group. It is not
>> clear if there is any real XML expert in the group who actually
>> understands XML at a deep level.
>
>
> Hmm, a group of people out there in the real world took a look at XML,
> picked what they thought they could use in their target environment, and
> ignored the rest. Reminds me of that effort at the W3C in the mid-90's
> to develop something called "SGML for the Web."
There are two issues that I can see with specifying more dirty than
quick XML subsets.
First, is that processors targeted to a subset get built, but are
named after the superset. Now, if someone wants to develop a SOAP
processor, they should go right ahead. What they should not do is
call it an XML processor - that muddies the waters. When they do, I
think we have every right to call foul. For example, over on
axis-user, I discovered thanks to Denis Sosnoski that XPP3 and
Electric XML don't process XML as per the spec. It's already been
discussed here that System.Xml defaults to a subset, and although
you can configure it to stop acting as System.SOAP and process XML,
I'm not sure about the other two (Denis says XPP3 can work with XML
with a parser swapout).
Second, XML is being subsetted for problem domains without much
visible thought for the cost of that subsetting. How are all these
optimized systems supposed to work together a few years out? There
are people who do not appreciate the value of what uniform format
offers, or what its potential economic value is. Perhaps this is
because we technologists are mentally stuck on foolish optimizations
in specification designs as well as software - we're still worrying
about the metal. Someone on axis-user said that making processors
comply with the more esoteric parts of XML would be compliance for
its own sake. But isn't compliance the point? If SOAP ever gets
subsetted, it will interesting to see how the web services community
reacts.
Subsetting XML seems as much an issue for 'interoperability' as
targeting schemas and infosets does. It's good news that people like
Don Box and Tim Ewald say they are now appreciating the value of
staying near XML syntax, but we might be some time waiting for
consensus that a finger food approach to XML was not such a good idea.
The people behind sml-dev got this right, technically and
economically - they specified the subset for everyone's use. Perhaps
similar work could be chartered by the W3C, or kicked off again on
xml-dev.
Bill de hÓra
|
