Re: [RESEND] Derivation by restriction

Hi Roger,

>> In our schemas we have a /lot/ of cases following a general
>> pattern:
>>
>> 1.  Declare an element to act as head of substitition group;
>> 2.  Declare non-abstract elements in the substitution group,
>> with a type derived from the type of the head by restriction;
>> 3.  Define a complex type which contains the abstract head element;
>> 4.  Define a restriction of the container which specifies that
>> a particular concrete member element is present.
>>
>> This appears to be pretty much how substitution groups were
>> designed to be used.
>
> Simon, I respectfully disagree. That is NOT how substitution groups
> were designed to be used. The intended purpose of substitution
> groups is to enable substitutability in **instance documents**. You
> are attempting to perform substitution in the **schema**, which in
> the least is bad practice, if not outright incorrect (I need to
> check the spec on this).

It certainly isn't *incorrect*. When a validator checks whether a
derivation by restriction is valid, it substitutes any particles that
are head elements of substitution groups with a choice model group
containing the head and members of the substitution group [1]. The
restriction is legal as long as it would have been a legal restriction
if that choice group had been defined originally.

I don't know whether using substitution groups as Simon is was
*intended* or not, but it certainly seems to be a growing pattern of
use. As I see it, when you define the content model for a type, you
can set constraints on the elements in the content at three levels:

 - constrain their namespace (using xs:any)
 - constrain their type (using substitution groups)
 - constrain their name (using normal element particles)

All of these are potentially useful types of constraints. And as I see
it, the constraints or lack of them can be useful both in the instance
(as you describe) and in the type hierarchy within the schema (as
Simon described).

Putting it another way: when you define a common type, to act as an
ancestor for a number of types, the commonality between the types
might be of several kinds:

  - they might contain the same element(s)
  - they might have the same attribute(s)
  - they might be used by the same element(s)
  - they might contain element(s) that have the same type

Using substitution groups as Simon is reflects the latter kind of
commonality, where two types contain elements of the same type,
usually used in the same way.

Can you explain more about why you think that it's bad practice?

Cheers,

Jeni

[1] http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict

---
Jeni Tennison
http://www.jenitennison.com/

Received on Thursday, 28 March 2002 08:59:24 UTC