- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 6 Mar 2006 08:47:18 -0500
- To: "Ramkumar Menon" <ramkumar.menon@gmail.com>
- Cc: xml-dev@lists.xml.org, xmlschema-dev@w3.org
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 --------------------------------------
Received on Monday, 6 March 2006 13:47:29 UTC