- From: Rick Jelliffe <rjelliffe@allette.com.au>
- Date: Thu, 09 Mar 2006 01:01:32 +1100
- To: xml-dev@lists.xml.org
- CC: xmlschema-dev@w3.org
Ramkumar Menon wrote: > Hi All, > > Needed a few clarifications. Would appreciate if someone cd comment > on the following. > > 1) Reposting the earlier question posted on xmlschema-dev -> Are there > plans to revisit the semantics of "xsd:all" in the upcoming versions > of XSD. > i.e removing the cardinality constraints on the items that can > exist within "xsd:all" ? > <> Are there any known issues/ambiguities introduced as a result > of unconstrained cardinality of items that can exist within xsd:all ? I am out of the XSD loop nowadays, but I don't expect you will see *any* significant evolution of XSD, apart from conceptual corrections and low-hanging fruit or to align it with commercially significant new specification such as XQuery. You can look http://www.w3.org/TR for material on XML Schemas 1.1 to see the kinds of changes that are being looked at. xsd:all is a good compromise that is better than nothing: * it could be regarded as syntactical sugar for a very large content model, so didn't require any thought about its theoretical impact * the assumption was that people would implement everything using an FSM (the rewriting technique used by TREX/RELAX NG wasn't well known) or that the obvious optimization for xsd:all might be put in * allowing unconstrained cardinality would easily lead to combinatorial explosion in the FSM * something like SGML's & operator or TREX/RELAX NG's interleave operator were not in any of the source schema languages that largely determined XSD from the outset: I think some working group members had a feeling that the WG would never finish if it deviated from that input set too much (as far as stuctures are concerned.) > <> 2) What is the rationale for disallowing choices between > attributes in XML Schema ? Please note that this scenario has had > repercussions on other specifications as well. [I am referring to WSDL > specifications that have this requirement, but have ended up with a > more loose definition for entites due to this restriction]. > A simple example is the "type" and "element" attribute information > items on the "part" element. These attributes are mutually exclusive, > but since there are no options in XML Schema to capture this scenario, > they have solved this by making both of them as minOccurs="0". When XSD started, there was I think no schema language* that allowed these kinds of co-occurrence constraints. The usefulness of such a feature was well outside the experience of people in the WG from a non-document background. (The same was true of the RELAX breakaways too: it was not obvious to people that co-occurrence constraints fitted in to grammars.) The problem is that even if you extend grammars to cope with attributes, you still don't get enough. There is no reason why all the important relations and constraints in some arbitrary database graph can be modelled (or expressed) well or thoroughly using a regular grammar, even a grammar extended with attributes. Given this fundamental limitation in grammars, there will always be the need for some extra layer, even if a slight one, to express these other constraints. Indeed, I fully expect that ultimately XSD will be used for datatyping and basic containment relationships only (i.e. "data dictionary" or "basic ontologies": people will find it simpler and better layered to handle order, occurrence, co-occurrence and link constraints using paths, which are better suited for this. The lack of co-occurrence constraints in XSD is only a problem because 1) You need to express those constraints, 2) XSD doesn't support them, and 3) You don't have in place a simple layer that can support them. Cheers Rick Jelliffe * I proposed doing them in grammars ("content models over different axes") at Academia Sinica but I failed to make my point clearly enough to be understood (the point being that a grammar is state machine, a context iterator, and an evaluation function which could use any axis.) Dave Raggett's 1999 Assertion Grammars had something that looked like it could do attribute-conditional typing, but it couldn't have been implemented because the tool generated DTDs. 1999's Schematron and XLinkit eventually got them of course, and eventually RELAX NG.
Received on Wednesday, 8 March 2006 14:02:05 UTC