[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Debating "civil disobedience" against overlycomplicatedspe

• From: "Simon St.Laurent" <simonstl@s...>
• To: "Champion, Mike" <Mike.Champion@S...>, xml-dev@l...
• Date: Mon, 24 Sep 2001 17:03:27 -0400

At 04:24 PM 9/24/2001 -0400, Champion, Mike wrote:
>There seem to be two rational ways that the XML community (e.g., the folks
>on this list) could address this.  The obvious one would be to try to shame
>the implementers into doing the right thing, for example by volunteering to
>write and perform conformance tests and publicize the results.  A corollary
>would probably be that you should lobby the SOAP WG into allowing PIs and
>DOCTYPE declarations (and the whole tangled mass of stuff that DTDs bring to
>the party) in SOAP messages.

Shaming isn't much fun, to be honest.  Lots of people/companies seem to 
lack a sense of shame and most everyone - those people included - seems to 
get psycho-defensive.  Sometimes that prods them into writing ridiculous 
replies, which can be entertaining in themselves, but it takes a long while 
and a lot of support to make shaming work.

>The other approach would be to lobby the W3C for a clean way to define XML
>feature profiles that applications could use to specify the contract between
>producers and consumers of data -- not just the elements, attributes, and
>values, but the other stuff such as acceptability of DTD internal subsets,
>CDATA sections, PIs, and various namespace declaration configurations. This
>would make the SOAP debate easy to resolve:  just use whatever magic profile
>string is required to tell the XML parser to treat DOCTYPE declarations and
>PIs as errors, then we have interoperability across SOAP implementations and
>between SOAP and generic XML implementations.

One thing that struck me today is some comments from Tim Berners-Lee[1]:
>Content-Types should be defined by URIs, as are XML Namespaces. These then 
>leverage the existing URI schemes to anchor thier meanings in the web. 
>This allows anyone to make a local private Content-Type or namespace for 
>their own use. This does NOT apply to URI schemes. The process has to be 
>rooted somewhere, and that root is the URI spec and the *small* set of URI 
>schemes

This would be a fairly sizable change, but I can imagine how such an 
approach would permit a much wider variety than the monolithic 
specification of RFC 3023 (which I'm quite fond of, having been a 
co-editor.)  The W3C in general would probably like to use that variety to 
expand what's included in XML (XPointer, XInclude, W3C XML Schema), but us 
simpletons (and SOAP) might be able to use the same or a similar mechanism 
for subsetting.  (Maybe URIs pointing to RDDL, with some vocabulary for 
describing which parts of XML are used...)

There are an incredible number of issues to think about on that front, and 
I strongly hope they are discussed more publicly and examined more closely 
than they were during the creation of Namespaces in XML.

>Simon St. Laurent, my usual partner in crime, seemed to by arguing against
>the latter "SGML-ish" approach in an earlier message.  He's right that this
>is out of synch with the XML philosophy of defining one basic syntax that
>all applications should understand.  But actual practice hasn't been kind to
>this philosophical notion; for whatever reasons -- good or bad, I don't want
>to re-open the "SML" debate! -- implementers of specialized processors have
>NOT been quick to support all the features that XML 1.0 defines.

Sure.  I've argued for a while that it's because XML 1.0 does too damn 
much, with an impoverished (broken?) notion of layering, but the philosophy 
has definitely suffered as a result.  It's a philosophy I still find far 
more attractive than SGML's "here's a huge pile of parts - use the one you 
want", but it seems to involve a level of discipline companies and 
consortia can't sustain.

>  The DOM
>defines various optional modules, and SVG has a requirement to define
>full/basic/tiny conformance levels in the next version; why not address the
>specialized simplicity vs generalized interoperability issue once and for
>all by defining multiple conformance levels in XML itself and letting
>applications choose the conformance level (or profile) that meets their
>needs?

I wish it didn't have to be this way, but I think we're likely stuck here.

>If it turns out that some conformance level/profile that matches what
>"developers think the XML specification says" is chosen by most application
>developers, then the minimalists will be vindicated; if it turns out that
>real-world application developers want the full power of all the stuff you
>can define in DTDs, all the "interesting" things you can do with namespaces,
>all the wonderful stuff that the PSVI lets the people (ahem, all 5 of them
><grin>) who understand it do ... then that's fine too.

Seems to me like a better idea than leaving a consortia to decide which 
tools we all must or must not use...

[1] - http://lists.w3.org/Archives/Public/uri/2001Sep/0016.html

Simon St.Laurent
Associate Editor
O'Reilly & Associates, Inc.

• References:
  • RE: Debating "civil disobedience" against overlycomplicatedspecs
    • From: "Champion, Mike" <Mike.Champion@S...>

• Prev by Date: Cooktop?
• Next by Date: RE: Debating "civil disobedience" against overlycomplicatedspecs
• Previous by thread: RE: Debating "civil disobedience" against overlycomplicatedspecs
• Next by thread: RE: Debating "civil disobedience" against overlycomplicatedspecs
• Index(es):
  • Date
  • Thread