W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2000

Minor comments on Part 1/22 Sept

From: Curt Arnold <carnold@houston.rr.com>
Date: Sat, 30 Sep 2000 14:12:01 -0500
Message-ID: <000b01c02b12$5273cb60$f00ba8c0@houston.rr.com>
To: <www-xml-schema-comments@w3.org>
I haven't had a chance to even fully scan the whole new docs, but I thought
I would try to put some of my initial comments together.

Section and

In later sections it is made explicit that anyType and anySimpleType are in
the http://www.w3.org/2000/10/XMLSchema , however it would be good to
mention that in the first mention.

Section 3.1 - Schema Information Set Contribution: Schema Information

Schema version (without dereferencing schema document) could also be useful

Section 3.7 - Nothing in the above...

What would be the implications of this for a: <choice minOccurs="0"/>
Should the schema be rejected?

Section 3.10: Identity constraints

I raised this after last call
.html)   In some instances, you can use unique to implement a prohibit
constraint, but it is ugly, but useful, kludge.  Adding an explicit
"prohibit" constraint would not appear to raise the complexity of schema,
but would have the beneficial effect of preempting the development of a lot
of kludgy schemas.

Section 4.1:

Summary does not show default ( : "") for blockDefault and finalDefault that
appear in the schema for schemas.

I still think that the annotation element should appear only once in the
content model of schema and representation an annotation of the schema as a
whole.  Allowing annotation elements to appear intermixed between top-level
components would result in people using top-level annotations to describe
the next sibling instead of the schema as a whole.

Section 4.3.1

The {value constraint} description in the non-global declaration appears to
make use="fixed" redundant (though it does make a "required fixed" behavior
finally available).  For example, it appears that fixed1 and fixed2 have the
same requirements, that the attribute is not required, but if it does appear
it must have the value "fixedvalue".  reqfix must appear and must have the
value "fixedvalue".

        <attribute name="fixed1" use="optional" value="fixedvalue"/>
        <attribute name="fixed2" use="fixed" value="fixedvalue"/>
        <attribute name="reqfix" use="required" value="fixedvalue"/>

If this reading is correct and their is not other behavior that
distinguished between fixed and optional, I would suggest removing fixed.
Thanks for adding "required fixed" however.

In the paragraph:  The names of top-level attributes...  The symbol space
for local scope attributes with no target namespace is discussed, but not
discussion of local scope attributes with a target namespace.  (A similar
issue occurs later with local scope elements).  I assume that for
locally-scoped qualified attributes {namespace URI, local name} must be

Section 4.3.2 and later

"or maxOccurs" appears in the element summary in a lot of the following
elements.  I assume that this should be something like:
"non_negative_integer | 'unbounded'"

"disallowed substitutions" has the phrase "normalized normalized value", is
this is intentional then I'm ignorant of what a normalized**2 value is.

Section 4.3.3: Complex

The tag names "complexContent" and "simpleContent" are confusingly similar
to "complexType" and "simpleType", I'd think something like "textContent"
and "elementContent" would be less confusing though maybe not as precise.

I'd agree with James Clark's comment
.html) about the position of attribute definitions.  It would be more
attractive to allow them appear at the head of a definition.

Section 4.3.10: XML Representation of Annotation Schema components

Almost every other element has an optional "id" attribute, it would be
useful if annotation, appinfo and documentation also had them.  Specially in
the case of documentation elements, having an "id" attribute makes it easier
to support external documentation files and multiple language documentation.
It can, of course, be done with external subsets or attributes from other
namespaces, but it would be preferable to have it as part of the schema for

Section 4.3.11

<union memberTypes = List of [anon]  ????

Section 5.11: Complex Type Definition Constraints

Constraint on Schemas: Derivation Valid (Extension), 1.1.2/1.1.3

On first reading, it appears to be saying that if you are extending a
complex type, you must repeat any attribute that occurred in the base type
which sounded like a constraint for restriction.  If "Its" refers to "{base
type definition}" then maybe, but it is ambiguous.  Is it trying to say:

1.1.1 The {attribute declarations} of the {base type definition} must be a
subset of the {attribute declarations} of complex type definition.... ?

If you want to use "Its", then it should also be used in section 1.1.1

1.1.1 Its {final} must not contain extension

Appendix F: Analysis of the UPA

Received on Saturday, 30 September 2000 15:11:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:48 UTC