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