Ramkumar Menon writes:

> 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" ? 

There is active discussion in the workgroup regarding these issues.  It's 
not yet clear whether any changes will be proposed for XML Schema 1.1. The 
fact that some users want this is clear.  That has to be weighed against 
implementation complexity, the time available to draft a good spec, the 
resulting incompatibility with XML Schema 1.0, and the question of whether 
a significant number of providers of schema processors would in fact 
support it.  As I say, there is very active discussion in the Schema WG, 
but it's premature to suggest what the conclusion will be.


>  Are there any known issues/ambiguities introduced as a result of 
unconstrained  cardinality of items that can exist within xsd:all ?

There are some complexities regarding restriction and extension.  In 
particular, XML Schema 1.1 is likely to take a conceptually simpler and 
more general approach to restriction than was in Schema 1.0:  if 
everything accepted by the derived content model is accepted by the base, 
then it's OK.  When you start messing with more complex all groups, you 
have to be a little careful about whether they can be restricted by 
combinations of sequences and choices, for example, and whether you can do 
the necessary checking without combinatorial blow up in the checker. We're 
trying to work through the analysis, and there is some chance that this 
will in the end not be a serious problem.

We've also had requests to allow all groups to extend other all groups, 
and adding occurrence constraints >1 would at least require us to 
establish some rules for extensions.  I think there are some reasonable 
designs possible, but we haven't set down all the details for evaluation.
 
> 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". 

The rationales were roughly: the language was already complex and we 
didn't think we could do a good job in Schema 1.0.  Actually, we get a lot 
of requests not just for choice between elements, but for "either this 
element or that attribute".  We also get asked for constraints involving 
the values of elements and attributes.  We call all of this co-occurrence 
constraints and we are asked for it quite regularly.  Now that datatypes 
is in last call, we have a short window for figuring out what will be in 
structures 1.1.  Co-occurrence constraints are in the top priority list 
for discusison, and there is a real chance we will propose something, but 
no guaranteees at this point.  We are certainly well aware of the demand 
from users.

I hope this is a useful answer to your question.  Thank you!

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





From petexmldev@t... Mon Mar 06 14:07:33 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3