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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: How to redesign W3C XML Schema (Was: Remembering the original XML vi

[ Lists Home | Date Index | Thread Index ]

At 12:26 PM 2/15/2003 -0500, AndrewWatt2000@aol.com wrote:
>In a message dated 15/02/2003 16:03:33 GMT Standard Time, 
>jonathan.robie@datadirect-technologies.com writes:
>
>>A smaller, simpler W3C XML Schema, with a careful redesign
>>that allows incompatibilities with W3C XML Schema 1.0, would be a very good
>>thing.
>
>Jonathan,
>
>This is a welcome comment. As you likely recall not a few on this list 
>would have liked to see (either at the time or in retrospect) the redesign 
>carried out before version 1.0 of W3C XML Schema was issued.

Yes, I recall vividly. As a matter of fact, I did a survey [1] which was 
posted on XML-Dev on 06 Jul 2000 in order to find possible areas of 
simplification, point out where the biggest problems were, and determine 
how strong the pressure to ship really was - because companies were saying 
it was extremely strong. One set of questions asked specifically how much 
time we could take for redesign:

10. What do you think the Schema WG should do:

[  ]  Ship as soon as possible, without significant change.
[  ]  Ship as soon as possible, making the prose more readable,
       but without changing the design of schema itself.
[  ]  Keep the current feature set, take one more shot to improve
       both the design of schema and the prose.
[  ]  Simplify the feature set, take one more shot to improve both the
       design of schema and the prose.

11.  If the Working Group were to spend time redesigning Schema,
what do you think we should spend our time doing?

12.  If you feel the Working Group should continue working on Schema,
how long would you be willing to wait for an improved version of XML Schema?

[  ]  Shoot the engineer and ship it now!
[  ]  6 months
[  ]  12 months
[  ]  18 months
[  ]  24 months

Here's an excerpt from the results [2]:

>
>Simplify the Design and Rewrite!
>
>
>
>Only 3 respondents felt that we should ship Schema as soon as possible, 
>without significant change. A further 4 felt that we should keep the 
>current design, make the prose more readable, and ship as soon as 
>possible. More than two thirds (24) felt we should work on the design, 
>saying either that we should keep the current feature set, and take one 
>more shot to improve both the design of schema and the prose (6), or 
>simplify the feature set, take one more shot to improve both the design of 
>schema and the prose (18).
>
>In fact, with 18 votes, this last choice by itself received support from 
>almost two thirds of respondents. Clearly, respondents felt it was 
>important both to simplify the design and to improve the prose.
>
>When asked how long they were willing to wait, almost half (13) said they 
>would be willing to wait 6 months. 7 respondents chose the option "shoot 
>the engineer and ship it now!", but 6 respondents chose either 12 months 
>(5), 18 months (1), or 24 months (1). Not only was 6 months the most 
>frequent choice, it is probably the best compromise to satisfy the group 
>of people choosing longer or shorter periods.
>
>When asked what a redesign should involve, respondents offered a variety 
>of suggestions, suggesting that we concentrate on modularity, simplicity, 
>readability, reusability, extensibility frameworks, removing features, 
>creating a minimal subset, or "dropping what is not well defined".

I thought there was great wisdom in the responses I read, and although 
individuals varied widely, I think I would have been in the mainstream if I 
had written a response to my own survey (which is not what you do when you 
write a survey!)

What happened, of course, is that we had a Candidate Recommendation three 
months later [3], and much of this work was not done.

>Would you also view the layering/modularisation of XML schema-related 
>capabilities as being equally desirable? To get rid of the phenomenon that 
>I have ... perhaps less than tactfully ... referred to as "schema fascism" 
>and fully open up W3C specifications for use with Relax NG and Schematron.

Yes and no. People can and will define all kinds of things on top of XML, 
with or without DTDs or W3C XML Schema. Nothing stops anybody from using 
Relax NG or Schematron, and I am actively interested in generalized 
extensibility mechanisms like the Schema Adjunct Framework.

On the other hand, a standards body needs to provide interoperable 
definitions of XML, and that includes validation. I don't think that the 
XML specification should say, "if you choose to validate, with some schema 
language, please refer to the definition of that schema language to see 
what it considers valid and what the resulting information content is." 
Validation is an important part of XML. I do think it is possible for the 
W3C to bless more than one schema language, and in fact, it already does. 
Two (DTDs and W3C XML Schema) is already awkward. Three would be more 
awkward, but I think it *would* make sense for the W3C to specify a third 
schema language: a simple, well designed language that used the same types 
as W3C XML Schema.

But I would only support it if it had a prayer of being implemented and 
used. Remember that XML was a marketing coup as much as a technical coup - 
if we wanted to establish another schema language, we would have to find 
markets that desperately need it, and for whom existing solutions are 
painful enough to make them willing to change, and to abandon already 
accepted standards. Building a market like that takes time and energy.

Jonathan


The reason we have standards bodies is to define interoperable 
specifications. I can't think of what it would mean to have XML governed by 
any schema

[1] http://lists.xml.org/archives/xml-dev/200007/msg00154.html
[2] http://www.ibiblio.org/xql/tally.html
[3] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/ 





 

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

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