[
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.
|
