Minor part 1 comments

Part 1/Section 3.4

A complex type for which {abstract} is true must not appear as the {type
definition} of an ElementDeclaration...

Actually, it would seem that you would allow it, but it would require that
the xsi:type specify a non-abstract type derived from the type used in the
declaration.

Part 1/Section 4.3.7

Wildcards are subject to the same ambiguity....   If an instance element
could match either an explicit particle and a wildcard, or one of two
wildcards, within the content model of a type, that model is in error.

If I had version 1.0 of a schema and wanted to create a variant that would
be forward compatible for a processing application (so that the processing
application would accept 1.0 valid documents and later revisions), I'd be
inclined just mechanically add <any> and <anyAttribute> elements, like:

<!-- definition in 1.0 schema   -->
<complexType name="pipe">
    <element ref="material" minOccurs="0" maxOccurs="1"/>
</complexType>

<!--  definition in 1.0+ schema   -->
<complexType name="pipe">
    <element ref="material" minOccurs="0" maxOccurs="1"/>
    <any minOccurs="0" maxOccurs="unbounded"/>
    <anyAttribute/>
</complexType>

Unfortunately, this would run into the Unique Particle Attribution issue and
would be in error by my reading.  In this simple case, it is fairly easy to
rewrite the permissive complexType as:

<complexType name="pipe">
    <any minOccurs="0" maxOccurs="unbounded"/>
    <anyAttribute/>
</complexType>

However, that could be much more difficult in complex real-life schemas.
Some sort of lower priority for wildcard matches that would allow the first
formulation while avoiding the attribute issue would be beneficial.

Constraint on Schemas: Particle Restriction OK (Elt:Elt - Name and Type
OK)/Point 1.1

{nullable} are the same: wouldn't it be a valid restriction if the base type
was nullable and the derived type inhibited xsi:null="true"

Section 5.11/Constraint on Schemas: Derivation Valid (Extension)/Point 1.1.2

Either I'm reading it wrong, or it is saying that you must fully repeat all
the attributes defined in the base type in the derived type.

Point 1.2.2

So if I have:

<complexType name="base">
    <anyAttribute/>
</complexType>

<complexType name="derived" base="base" derivedBy="restriction">
    <attribute name="value" use="required"/>
</complexType>

Does this still allow any other attribute to appear, but value is required?
If so doesn't that run into the Unique Particle Attribute issue.


Point 1.3:

Is this saying that if my base type definition has a required attribute, I
have to repeat in a derived by restriction type?

Section 5.12/Constraint on Schemas:Derivation Valid

Point 1.2(.1?) This would seem to disallow adding new facets in the derived
type

<simpleType name="derived" base="xsdt:string">
    <!--  this facet isn't declared for string   -->
    <pattern value="\d*"/>
<simpleType>

Received on Thursday, 11 May 2000 00:56:49 UTC