- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 8 Jan 2002 17:24:22 +0000
- To: Patrick Lisser <patrick.lisser@canoo.com>
- CC: xmlschema-dev@w3.org
Hi Patrick, > So the <xs:choice .... </xs:choice> part is dublicated. To simplify > (and to express that it's really 2 times the same) I'd like to > consolidate it and I see two possibilities to do so: > > 1. I extract the part, add and use it as a group: [snip] > 2. Specify a abstract type and substitute it in the concrete menu > entries: [snip] > What are the advantages and disadvantages of both solutions? Are > there recommendations on what should be preferred under certain > circumstances? I could imagine that if part of the schema (i.e. the > group/abstract type) would be external and not modifiable for those > who wanted to add new concrete menu entries, the choice should be > the abstract type, however in my situation this is not the case. Interesting question. Differences that leap out at me: Model group control: When you use a substitution group, you get a very basic choice, with the min/max occurrence of the head element determining how many occurrences there can be of the other elements. On the other hand, with a xs:choice in a xs:group you can force different elements to be repeated different numbers of times or, if you need to later on, refine the model group to give tighter control over the content. Namespaces: When you use a substitution group, all the elements have to be declared at the top level of the schema, as global elements. This means that they must all be in the target namespace for the schema. On the other hand, if you declare the elements within the xs:group, they are local elements and could be in no namespace (unqualified) instead. Naming conflicts: In general, declaring global elements leads to the possibility of conflicting element declarations - if you had another element of the same name but with a different type, and this element also had to be declared at the top level of the schema (because it was the document element, or because it was a member of a substitution group too) then you would run into difficulties. Multiple groups: An element can only belong to one substitution group, but (if it's declared as a global element) it can be in multiple xs:groups. So if you have the same issue with a group involving the same element elsewhere in the schema, it probably makes more sense to use xs:group throughout. Extending into different namespaces: If someone were to take your schema and want to extend the choice group to include elements in their own namespace, the amount of effort they would have to go to is different in the two cases. To extend the xs:group, they'd have to create an 'adapter' schema in your namespace that redefined the xs:group, adding references to the elements in their namespace. On the other hand, with a substitution group they just need to declare their elements (at the top level) and point to the abstract substitution group head element, effectively extended the choice with their own elements. The same issues are involved with extensions in the same namespace, but the effort is slightly less marked. Control over element types: Using a substitution group gives you some control over the content of the extra elements that other people might add, because the types of the elements that are members of a substitution group must be derived from the type of the head of the substitution group (your abstract element). On the other hand, people could put all sorts of elements in the xs:group if they redefined it. I think my conclusion is that if you're fairly happy that you're not going to need to change your basic schema (and assuming that it doesn't contain any conflicts), want to make it easy for people to extend the allowed elements, and especially if you want to control what kinds of elements they can extend with, go for a substitution group. Otherwise, use a model group. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Tuesday, 8 January 2002 12:24:24 UTC