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] Internal entities removed from XML?

[ Lists Home | Date Index | Thread Index ]

On 19 Dec 2002 11:57:50 +0100, Eric van der Vlist <vdv@dyomedea.com> wrote:

> To quote John Cowan [1], the golden rule for interoperability is "Be 
> liberal in what you accept, conservative in what you send" and I had 
> always understood
> Common XML as a set of conservative rules to be used for what you send
> if you want to avoid any interoperability trouble.
> Using it the other way round to be conservative in what you accept would
> on the contrary bring you a lot of troubles would be a disaster IMO !

That certainly is a good point.  I may be so infatuated with the idea that 
the Powers that Be have independently discovered the principles that we 
carved out here about three years ago during the great SML permathread that 
I'm blinded to the problems with implementing them at the API level rather 
than in standard profiles.  Whatever ... my interest here is not in 
advocating that the industry adopt the MS approach to the problem, just in 
pointing out that the question of profiling is Out There and has to be 
dealt with.  MS may be dealing with it badly (I really don't know enough 
about what they actually do in the .NET API to have an informed opinion), 
but the appear to be dealing with it.

"Standards" (especially industry consortium specs as opposed to de jure 
standards) that deviate from actual practice become irrelevant.  The actual 
practice of a lot of the data-oriented integration-driven XML applications 
seems to implicitly deprecate much of what is in the XML specs.  If MS is 
optimizing their software and setting their defaults for the common case 
rather than the full spec, that is a *symptom* of something that needs to 
be addressed, IMHO. Some seem to want to address it by evangelizing the 
importance of supporting and exploiting the whole spec, some want to 
address it by accomodating the specs to the reality that many have voted 
with their feet against big chunks of the XML Recommendation.  (To be 
clear, I'm talking about "legalizing" one or more profiles, a la the XML-SW 
proposal, not formally deprecating DTDs ... that is obviously not the right 
thing for a big chunk of the XML users out there!).

So, in my idealized vision of the future, things like the SOAP profile (XML 
1.x - DTDs + namespaces + [xml:id?  some simple xsi types?])  could be the 
advertised dialect that a producer produces and a consumer consumes. Sure, 
that has downsides ... my basic point is that those downsides are out there 
right now.  For example,a message that validates against the SOAP schema 
SHOULD (or MUST, can't remember offhand) be rejected by SOAP processor if 
it contains a DTD internal subset or PIs.  [Whether this is a Good Thing or 
not has been beaten to death on xml-dist-app and www-tag, let's not go 
there.] In that situation, "be liberal in what you accept" *degrades* 
interoperability just like it does when alleged "XML" processors accept 
something that is ill-formed.    I just think that a situation where there 
was some standardized way for an XML processor to be told what dialect to 
expect, and what to do if the constraints of that dialect are violated, 
would put us in a better situation than we are now.


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

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