Re: Comment on XSD 1.1

Pete Cordell wrote:
> I'm just trying to understand what you're proposing.  We come from 
> different worlds.  In my telecoms background, higher layers add 
> functionality based on the services of the lower layers.  Hence I 
> think we have a terminology mis-match.  Since even within the telecoms 
> world there are terminology confusions (and terms often vary according 
> to the context!) I don't think it's too surprising that in a 
> cross-displine discussion some terminology needs to be clarified.
Of course.
>
> In the terminology of my world I think what you're proposing is more 
> akin to defining profiles, each of which may, in a deviation from pure 
> profiling principles, add a small bit of additional functionality.
Lets flop to a vertical terminology then: if you imagine a continuum 
with RELAX NG at the left and XSD at the right.

Moving from the left to the right involves adding more apparatus for 
labelling productions (in terms of higher concepts such as simple types, 
complex types, groups and so on.)  While RELAX NG has the ability to 
express these kinds of groupings, it does not have a mechanism label 
them nor to make assertions about productions with different labels 
(e.g. type derivation by restriction checks): you can make a production 
that contains only the enumeration of text values, and use this 
production to constrain a particular value, but you never say "I am 
declaring a simple type."*  

(We may recall that creating XSD involved, to a large extent, an 
excercise of "reconstructing" DTD facilities: looking at what DTD 
parameter entities did, and giving these uses first class status such as 
complexType and attributeGroup. Converting from XSD largely involves 
throwing away this typing apparatus, while still validating the 
constraints in them.)

Moving from the right to the left involves increasing the power of the 
language, measured as the different class of documents that can be 
described and validated.  RELAX NG is more powerful. XSD has its UPA and 
name restrictions, while RELAX NG does not. Indeed, this relaxation of 
constraints is what gives RELAX NG its name, IIRC.

I contend that the move to the right is indeed merely an adding of 
apparatus, and therefore (could be implemented as) exactly what Peter 
would think of as a layer (as far as the grammars go.)  An XSD schema 
can be assembled, checked for UPA and non-RELAX NG schema constraints, 
then the document validated using that schema converted to RELAX NG 
(then addition non-RELAX NG document constraints checked, if any 
exist).  Take UPA violation: this is determined by examining the content 
model, not the document. So if the content model is tested to not 
violate UPA, the instance can be validated even by a parser that is not 
restricted to one-ambiguity.

Moving from the left to the right also involves an augmented set of 
standardized outcomes.

* Not to be confused with the RELAX NG datatype library mechanism.

So I think that XSD can be imagined as a "layer" above RELAX NG, in that

  1) It adds certain content model checks and adds on typing apparatus
  2) It restricts the power
  3) It adds more outcomes

This is not a layer in the way that HTTP is a layer on top of TCP/IP (or 
UDP/IP or whatever), but a layer in the sense that C++ is a layer above 
the C language.

>  
> I think a modular approach would be better.  
It certainly would be. Indeed, that is the premise of ISO DSDL: smaller 
targeted languages that can be combined and built upon. And, indeed, 
that is the premise of my suggestion: that full XSD and the databinding 
patterns profile can both be formulated in terms of layer/modules on top 
of RELAX NG.   But insisting on full modularity in XSD as a big bang 
looks like a fantasy at this time: it is XSD 2.0, while I am concerned 
with XSD 1.n Minimal.

I don't want to obscure my point: which is that we have two real 
terminal points (RELAX NG and XSD 1.0) and a concrete, objective hull 
and kernel of features in the middle (the Databinding patterns 
documents) with a set of features basically of DTDs plus XSD's built-in 
datatypes.   We have lots of evidence about which features of XSD are 
less common and which are more common, even outside the periphery.

We can use this objectively to say "What is the language created by the 
intersection of RELAX NG and XSD that also fits between the hull and 
kernel of the datatyping patterns?"  I think this is entirely pragmatic 
and workable, and would avoid the paralysis-by-analysis that has reigned 
so far, and the inability to justify anything apart from growth by the 
XSD WG. More to the point, it would provide a much more reasonable 
target for users and systems that only need a modest XSD, such as the 
databinding. (To the extent that a modular approach would open up to 
innovation and theoretizing and stray from these achievable goals, 
modularization fwould be a bad move.)

Just as WF XML is also conforming SGML (with only the slightest change 
to the SGML standard to accomodate it), I am wanting the stripped-down 
XSD to also work with full XSD systems with only perhaps the slightest 
change to XSD syntax if necessary. (And also to be convertable to RELAX NG.)

And this is why I think XSD 1.1 should be put on hold. Finding this core 
common language would not be a death march task: and it would be better 
for XSD 1.1's changes to be made in the context of any tweaks needed to 
support this core.

Cheers
Rick Jelliffe

Received on Wednesday, 20 May 2009 07:04:06 UTC