OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   The Tool X horror scenario (was RE: Begging the Question (the nov el)

[ Lists Home | Date Index | Thread Index ]
  • From: Mike.Champion@SoftwareAG-USA.com
  • To: xml-dev@lists.xml.org
  • Date: Sat, 30 Dec 2000 15:21:55 -0500

Title: The Tool X horror scenario (was RE: Begging the Question (the novel)


> -----Original Message-----
> From: Lisa Rein [mailto:lisarein@finetuning.com]
> Sent: Saturday, December 30, 2000 2:27 PM
> To: Uche Ogbuji
> Cc: Andrew Layman; 'xml-dev@lists.xml.org'
> Subject: Re: Begging the Question (the novel)

> I'm thoroughly confused about how anyone who thoroughly
> understood XML Namespaces could argue about this whole "Tool X" taking
> over the world  with the evil defacto schema implementation bull.

The example that the "Tool X" discussion brings to my mind is Microsoft's implementation of a draft XSLT spec in IE5.  Even though this was done with the best of intentions, and MS has worked very hard to provide updates that supported the XSLT Recommendation, IE5 became an "evil defacto implementation" that has caused immense confusion and additional work for the foot soldiers of XML. 

I could easily imagine a similar round of confusion if some popular tool (IE6, or Xerces perhaps?) -- with the best of intentions, and in full compliance with the letter of the namespaces spec -- were to offer some added functionality *if* namespace URIs point to some specific type of object. (If you really want a nightmare scenario, imagine that it is some proprietary object, not one defined by an open standard). As the history of HTML shows, the Ordinary Joe developers of the world care a lot more about the "standards" defined by the behavior of popular tools than by the words in some document on the W3C website. 

So, the problem is NOT with the people who thoroughly understand namespaces ... but with the people who think that namespaces look like URLs, and Tool X treats them like URLs pointing to some sort of object, and then raise hell with all the vendors whose tools do NOT treat namespaces like Tool X does.  Just as many of us, on many mailing lists, have patiently explained over and over and over that the XSLT language that IE5 supports is not the one that the W3C Recommendation defines, so one should not expect it to interoperate with other tools ... so I can imagine spending the next few years patiently explaining that the behavior of Tool X is *consistent* with the namespace Recommendation but not what is *required* by the namespace Recommendation, so that behavior should not be expected by other tools. 

I'm not sure that I agree with the argument that we can best avoid this scenario by deprecating URLs as namespace IDs (this *would* play havoc with RDF).  I can see  value in Paul Tchistopolskii's suggestion that namespace IDs that are NOT dereferenceable be specified as something other than URLs.  That could entail a revision of the Namespace Recommendation ... or perhaps it should be promulgated as a "best practice" without formal sanction.  In any event, to echo a point that has been made repeatedly in this thread, we should take the massive confusion on this subject AMONG XML "EXPERTS" as a strong indication that something needs to be done before the confusion spreads too far among XML "customers".





 

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

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