Re: XSD feature check-lists

Dear Noah,

While I see your point, I feel that XML schema is about 10 to 20 times more 
complex than an XML parser (a rough estimate based on implementation 
experience).  Therefore, it isn't necessarily appropriate to extrapolate 
what has worked well for XML to XML schema.

I also wouldn't expect vendors to fill in a feature profile and never work 
on their code again.  Quite the contrary - I can see that a feature matrix 
could be quite a battle ground and motivator for vendors to implement 
features so that they can out do their competition.  This would ratchet up 
the level of support among vendors.

The result would be that customers would have a clear picture of what is 
available, and vendors would know where they need to do better.  If feature 
support wasn't 100% after a while, standards people could go on about 
vendors not properly implementing standards and add pressure based on hard 
evidence!  Looks Win-Win-Win to me!

Regards,

Pete.
____________________
Original Message From: <noah_mendelsohn@us.ibm.com>

> Pete Cordell writes:
>
>> I don't know whether this has been suggested
>> before, but as an alternative to defining domain
>> specific profiles of XSD, maybe the W3C can define
>> an official, standard checklist of features that
>> vendors can fill-in and display on their web
>> sites.  This would give customers an equal basis
>> for assessing products, and give vendors guidance
>> on where they can improve their products.
>
> I think that encouraging vendors to be honest about the status of their
> products is a good thing, but appearing to encourage subsets is not.  How
> would we feel if for XML itself we suggested a checklist along the lines
> of:
>
> _ do you support attributes?
>
> _ do you support entities?
>
> _ do you support the short form of empty tags?
>
> _ do you handle whitespace correctly?
>
>
> etc.  XML interoperability would be seriously damaged.  The point of XML
> is that you don't get a choice about these things and we don't encourage
> reporting of subsets.  We tell you not to claim you're XML-compatible
> until you do all of these things.  As a result, customers find that XML
> interoperability is pretty good.
>
> The same concern applies to schema.  While a few vendors are still having
> particular trouble and that is causing unfortunate confusion, my
> impression is that a number of the more careful XML schema validators are
> showing quite good conformance and interoperability.  Of course, there are
> some things like data binding tools that aren't even trying to support the
> whole language, though some of the things they subset are in XML not
> schema (e.g. mixed content.)
>
> Bottom line: while schema does have well known complexity issues, I think
> we should be very reluctant to promote ad-hoc subsetting in particular
> implementations.  I'm afraid that publishing a matrix in which you can
> document your non-conformance may appear to do just that.
>
> If you're talking about things like databinding tools, I support what I
> took to be the consensus of the recent schema workshop:  tools should
> support all of schema and XML, but should optimize the subsets most likely
> to be heavily used and/or a good match to the environment.  A checklist to
> document such a subset may make sense, and I think that as a result of the
> workshop the W3C is considering a closer look at that area.
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>


--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

Received on Thursday, 4 August 2005 08:31:00 UTC