Potential errata for Substitution Group and Type Derivation checking

Hi all. Got some questions:

[1] substitution group

Consider the following schema: there are two global element declarations:

<element name="e1" block="substitution"/>
<element name="e2" substitutionGroup="e1"/>

Then in some complex type:

<choice>
  <element ref="e1"/>
  <element ref="e2"/>
</choice>

(I omitted the namespace prefix, but I think you get what I mean.)

According the structure spec, the above choice violates Unique Particle
Attribution constraint, because "e2" is in "e1"'s {substitution group}.

But "e2" can never substitute "e1", because of the "block" attribute on
"e1". That means we are reporting an error for a potential confliction that
could never happen!

To solve this, I would like to see the definition of {substitution group}
(the last constraint in 3.3.6) to be changed to

"Schema Component Constraint: Substitution Group

[Definition:]  Every element declaration (call it E) in the {element
declarations} of a schema defines a substitution group, a subset of those
{element declarations}, as follows:
1. The element declaration itself is in the group;
2. If any element declaration S in the {element declarations} together with
E's {disallowed substitution} is validly substitutable for E as defined in
Substitution Group OK (Transitive) (§3.3.6), then S is also in the group."

[2] type derivation checking

The following sentence appears some times in the spec, but it's quite
confusing:

"type definition A must be validly derived from type definition B given its
{prohibited substitutions}, as defined in Type Derivation OK (Complex)
(§3.4.6) (if it is a complex type definition), or given the empty set, as
defined in Type Derivation OK (Simple) (§3.14.6) (if it is a simple type
definition)."

Problems:

1. What does "it" refer to in "its {prohibited substitutions}"? Type A or
type B?

I guess the answer is type B, because we should consider the {prohibited
substitutions} on the base, not the derived type. But it's not clear to me.

2. What does "it" refer to in "if it is a complex/simple type definition"?

Now "it" seems to mean type A. Otherwise if it's type B, then consider the
case where A is a complex type and B is a simple type. Now since B is a
simple type, we should use constraint "Type Derivation OK (Simple)". But
this constraint only applies to the case where both types are simple type.

3. There is no type derivation constraint for the case where A is a simple
type and B is a complex type. Then how do we check whether the type
"string" is a valid derivation from "anyType"?


It would be greatly appreciated if someone could clarify on these
questions, or correct me if I'm wrong.

Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com

Received on Tuesday, 16 October 2001 14:56:42 UTC