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.

From rjelliffe@a... Wed Mar 08 14:16:16 2006
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org w