Re: group or abstract type?

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