Lists Home |
Date Index |
> On Sun, 02 Feb 2003 12:39:53 -0700, Uche Ogbuji
> <firstname.lastname@example.org> wrote:
> > But yes, rejecting XML documents that use DTD is a violation of XML's
> > fundamental design. Or do you claim that DTDs are not a part of XML's
> > fundamental design?
> In the current situation compliant XML tools can validate a SOAP message
> against the relevant schemata, but a SOAP-compliant processor will reject
> it if it has a DTD (external declaration or internal subset), a PI, etc.
Which is the problem. SOAP is not XML, and should stop saying it is so.
Folks, Plain XML in the payload of an HTTP message with a few extended headers
is far superior to the welter of nonsense that WS has managed to conjure up.
I used to appreciate Paul Prescod's point that the significant contribution of
SOAP is the extensibility XML gives header formats. It didn't take me long to
see that the huge costs of dogmatic Web services outweighed that paltry
benefit. Ans anyway, if I want that, I'd rather just stuff an XML EPE into a
extension HTTP header. Then again, the only case where I've seen this
shortcoming of plain MIME headers in practice is good old
Content-Type: text/html; charset=iso-8859-1
And come on, that's not *all* that bad. So why am I supposed to care about
SOAP again? Oh yes, the wizards I can use to generate "web service
end-points" from programming language code. My years in the SOAP trenches
just makes me laugh myself half to death at that notion: I would probably have
been twice as productive if every time I reached for a SOAP toolkit I instead
just coded straight XML in HTTP. And this represents experience with Python,
Java and C WS tools.
So as far as I'm concerned, SOAP is not XML, nor is it useful to even a
fraction of the degree to which it is destructive.
> The issue on the table, as I understand it, is whether the "XML" world
> (broadly defined) is better off with the status quo or in a world where
> some "profile" is established whereby "XML" tools can be either optimized
> for the profile, or put into "profile mode" where they would flag as errors
> the use of constructs not in the profile.
Again this is the fork. Just go ahead and fork, but be wise enough to make
the fork explicit, rather than wiggling it sub rosa into all the places where
it can do the most violence to interoperability.
> ... without getting tangled up in the bits that PRACTICAL EXPERIENCE HAS
> SHOWN to have different costs-benefits in the data-oriented and document-
> oriented worlds (entity references beyond the built-in ones being the usual
Please turn off those silly caps. Now reflect that XML came from the
document-oriented world. The data-oriented world really just needs CSV with
better support for hierarchies. Fine, as I said in another post. I don't
even think that's a bad idea. Just don't make matters untenable for everyone
by calling that CVSTree thingie XML, or by trying to turn XML into CVSTree.
Once again, fork and fork cleanly.
> <religious-analogy-beaten-into-the-ground> IMHO, It's time for
> ecumenicalism, not fundamentalism ... time to welcome innovators into the
> mainstream rather than driving them out as heretics ... time to accept the
> fact that XML is continually evolving from what survives in the real world,
> not invented by an omniscient Creator. </religious-analogy-beaten-into-the-
Analogies suck. This one is worse than most. I could call WS the
fundamentalists by forbidding constructs which are allowed in XML, for example.
You will get farther in this argument by just saying what you mean. If you
mean that we should not abuse people for inventing new data representation
languages, then I'll say I agree with you, and I'll wonder who was doing such
a thing. My argument is not with any effort to create CSVTree or whatever, my
argument is with the insistence that the people who invent CSVTree call their
new language "XML".
Please notice that I have expressed nothing but admiration for Durusau's work
on JITTs, Tennison's on LMNL, and the group behind YAML. I have nothing
against creativity and exploration. Now what could it possibly be that
separates these efforts from the sneaky tactics of the WS crowd? Whatever
could it be?...
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
The open office file format - http://www-106.ibm.com/developerworks/xml/library/x-think15/
4Suite Repository Features - https://www6.software.ibm.com/reg/devworks/dw-x4suite5-i/
XML class warfare - http://www.adtmag.com/article.asp?id=6965
See you at XML Web Services One - http://www.xmlconference.com/santaclara/