[
Lists Home |
Date Index |
Thread Index
]
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.
|
