W3C home > Mailing lists > Public > public-xsd-databinding-comments@w3.org > January 2007

Comments on the last call working draft

From: Priscilla Walmsley <pwalmsley@datypic.com>
Date: Mon, 15 Jan 2007 08:27:42 -0500
To: <public-xsd-databinding-comments@w3.org>
Message-ID: <01aa01c738a8$f030f530$6501a8c0@WALMSLEYPH>
Hi all,
After rereading the last call working draft, I had a few comments.  They are
below.
Thanks!
Priscilla Walmsley

Overall
- Everywhere it says "document or element node", I think it should just say
"element node".  A document node would never be returned by .//xs:schema;
the xs:schema element would be a child of the document node in the case that
it was the outermost element.
- Everywhere it says "node-set" it should say "sequence".

QualifiedLocalElements
- It might be more illustrative to show an example of a locally declared
element in the schema and have the instance element be prefixed

UnqualifiedLocalAttributes
- It might be more illustrative to show an example of a locally declared
attribute in the schema and have the instance element carry that attribute

ElementFinal
- Only global elements can validly have the @final attribute, so the path
could start with ./xs:element instead of .//xs:element

ImportTypesNamespace
- I don't see how this could represent a valid schema, since the XML Schema
recommendation says, about import, "If the namespace [attribute] is present,
then its .actual value. must not match the .actual value. of the enclosing
<schema>'s targetNamespace [attribute]."

GlobalElement and GlobalAttribute
- The "@name and " is redundant since all global element/attribute
declarations have to have name attributes
- I'm not clear why we're checking whether @type contains a colon? The type
attribute could still contain a name that's in a namespace but not prefixed,
if a default namespace is declared.  Is it because some processors might
handle prefixed names differently from non-prefixed ones?  If this is the
case, shouldn't we have two patterns: GlobalElementPrefixedType and
GlobalElementUnprefixedType?  Same comment on ElementTypeReference
ElementReference, AttributeTypeReference,  and AttributeReference

GlobalElementSequence
- The [@name]  is redundant since all global element declarations have to
have name attributes
- This pattern doesn't rule out types where there is something else besides
elements in the sequence, for example:

<xs:element name="globalElementSequence">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="foo" type="xs:string" />
      <xs:element name="bar" type="xs:string" />
      <xs:choice>
        <xs:any/>
        <xs:group ref="xxx"/>
      </xs:choice>
    </xs:sequence>
  </xs:complexType>
</xs:element>

It seems that such a type shouldn't conform to a basic pattern. Maybe it
should be something like:

./xs:element/xs:complexType/xs:sequence[xs:element and not(* except
(xs:element, xs:annotation))]/ 

Or is the idea that it's the foo and bar elements that are the ones that
conform to the pattern?  Same comment for ComplexTypeSequence


ElementMaxOccursFinite
- Could be simplified: .//xs:element[@maxOccurs != ('0','1','unbounded')]


ElementEmptySequence
- The [@name] is redundant because an xs:element without a name could never
have a complexType child
- Instead of not(node()) which would return true even if there was
<sequence> </sequence>, should it be not(*) or not (* except xs:annotation) 

ElementEmptyComplexType
- The [@name] is redundant because an xs:element without a name could never
have a complexType child
- Instead of not(node()) which would return true even if there was
<complexType> </complexType>, should it be not(*) or not (* except
xs:annotation) 

Section title "Global SimpleType Declarations" 
- Technically, according to the Schema rec, types have _definitions_ and
elements/attributes have _declarations_, so this should be changed to
"Global SimpleType Definitions". (May occur in other places too.)

GlobalSimpleType and GlobalComplexType
- [@name] is redundant since top-level complex types always have names

StringEnumerationType
- The path doesn't eliminate simple types that combine xs:enumeration with
other facets. Should it?  I wouldn't think the following type would conform
to the basic pattern:

<xs:simpleType name="Beatle">
  <xs:restriction base="xs:string">
    <xs:enumeration value="John" />
    <xs:enumeration value="Paul" />
    <xs:enumeration value="George" />
    <xs:whiteSpace value="collapse"/>
    <xs:maxLength pattern=".{4,6}"/>
  </xs:restriction>
</xs:simpleType>
Received on Monday, 15 January 2007 13:34:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:10 GMT