W3C home > Mailing lists > Public > www-tag@w3.org > May 2009

Re: Comment on XSD 1.1

From: Rick Jelliffe <rjelliffe@allette.com.au>
Date: Thu, 14 May 2009 05:57:18 +1000
Message-ID: <4A0B261E.1080706@allette.com.au>
To: Pete Cordell <petexmldev@codalogic.com>
CC: www-xml-schema-comments@w3.org, www-tag@w3.org
Pete Cordell wrote:
>
> I'm not sure how a base layer that is not streamable can have a layer 
> added to it that makes it streamable.  Am I missing something?
That different layers can have different restrictions or extensions that 
give them different implementation characteristics
should be obvious: this is the real world, not the artificial one of 
facets and type derivation where properties cannot emerge but always 
need to be present in the base!  If you want to think of it that the 
layers may both extend and restrict the previous layer, that is OK.  
Streaming in particular is not something to get hooked up on: I only 
mentioned that because it might be desired that the least constrained 
base version allowed full Schematron assertions with full XPath while 
the XSD 1.1 layer had the streaming subset. But it would be simpler for 
discussion to leave assertions and Schematron out of it, because they 
are subsiduary to the grammar issues.

In concrete terms, the layering might look like this:

Layer 1: RELAXSD    - targeted at standards and publishing and languages?
     Complete RELAX NG using XSD syntax to the maximum extent.
     In particular no concept or markup for type derivation, just 
reference.
     This will be trivially convertable to and from RELAX NG and RCS.
     Accepted as a lump of functionality, not debated or reinvented a la 
NIH.

Layer 2: Databinding XSD   - targeted at databinding and small messaging?
     Layer 1 with 1-ambiguity requirement plus any XSD components that
     are allowed by the XML Schema Patterns for Databinding document
     but still no features for type derivation. A schema in this layer will
     be runnable by all software implementing layer 1 and layer 3 too.
     This will be mostly convertable to and from RELAX NG and RCS.

Layer 3: XSD 1.1 - targeted at database and storage or type-centric 
applications?
      XSD 1.1 reformulated with any current trimmings and ugliness that 
are too
     good to miss or too difficult to jettison.It can steer in the 
direction of helping
     optimize database queries without

>
> And my two cents on other issues...
> - Restricting the range of integers and length/patterns of strings 
> seems useful for the base layer.
Certainly. RELAX NG supports facets on XSD  built-in types. The RELAX 
standard is at 
http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
for anyone interested.

> - I don't think arbitrary values for minOccurs/maxOccurs (as opposed 
> is ?, , *, and +) are a problem.
That is what
    http://www.w3.org/TR/xmlschema-patterns/#group-Element
says, unless I have missed some production.
> Which really points to different people wanting different things so 
> sub-setting XSD into layers is going to be a problem.  It's probably 
> best to start afresh.  I that respects I agree with Michael's 
> sentiments of letting XSD 1.1 go forwards and then working on 
> something new.
There is already "something  new"  that provides a great input for 
solving this. I don't know why we should have
confidence that the XSD WG would not just recapitulate the flaws of XSD 
into a new standard, especially given
the natural human tendency towards NIH.

And I don't think it is practical to expect that somehow XSD would go 
away. It will be around in 20 years. Which
is why I favour */raproachment/* 
<http://www.google.com.au/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla:en-US:official&hs=b5z&ei=oiMLSrqDEIf6kAXwoqirCw&sa=X&oi=spell&resnum=1&ct=result&cd=1&q=raproachment&spell=1>.  
I know, for example, that Michael MacQueen has done work on relaxing the 
ambiguity restrictions in XSD to something more like RELAX NG. I 
remember when the WG was discussing whether XSD should allow ambiguity 
or not that I wrote a tentative note that pointed out the useful 
properties such as implementation by state machines, and the WG kept 
with unambiguous (or 1-ambiguous, or is it 1-unambiguous?) content 
models. It is clear that that constraint belongs to Level 2, but it does 
not need to be in Level 1, and in fact I don't know whether it needs to 
be in level 3. But having Level 1 with it takes the pressure of level 3 
(XSD) to change.

I hope this gives more of a shape to the approach I think would be 
practical and useful.

Cheers
Rick Jelliffe
Received on Wednesday, 13 May 2009 19:58:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT