Forwarded message 1
Allowing the latter schema causes problems because it means that each
named element has a different element declaration. This still causes
problems for XPath 2.0 and XQuery because QName no longer uniquely
determines a local element declaration which now breaks the
SchemaContext mechanism for validating local types[0]. Also nillability
can be considered conceptually as part of the type and shouldn't be
something that can vary between local element decls with the same name
similarly to how having differing types in that situation is
constrained.
I think the W3C XML Schema working group should consider whether this
was actually an intentional decision or something that actually is
worthy of revisiting.
[0] http://www.w3.org/TR/2002/WD-xquery-20020816/#doc-SchemaContext
--
PITHY WORDS OF WISDOM
Never make anything simple and efficient when a way can be found to make
it complex and wonderful.
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>
> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@cogsci.ed.ac.uk]
> Sent: Tuesday, November 05, 2002 10:38 AM
> To: Dare Obasanjo
> Cc: xmlschema-dev@w3.org
>
> "Dare Obasanjo" <dareo@microsoft.com> writes:
>
> > A local decl doesn't make it different. That was part of my
> "No" answer.
> >
> > I have a followup question involving Element Declaration
> Consistent.
> > It seems to disallow
> >
> > <?xml version="1.0" encoding="UTF-8"?> <xs:schema
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> >
> > <xs:element name="root">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="foo" type="xs:string" >
> > <xs:element name="foo" type="xs:integer" />
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > </xs:schema>
> >
> > yet allow
> >
> > <?xml version="1.0" encoding="UTF-8"?> <xs:schema
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified" attributeFormDefault="unqualified">
> >
> > <xs:element name="root">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="foo" type="xs:integer" default="10" >
> > <xs:element name="foo" type="xs:integer" fixed="5" />
> > <xs:element name="foo" type="xs:integer" nillable="true" />
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > </xs:schema>
> >
> > is this by design or an oversight in the recommendation? It seems
> > rather arbitrary to disallow one and not the other.
>
> You're right about what's in and what's out, and it is by design.
> This constraint is there so that type inference from XPath
> expressions is straight-forward, as I recall. That is,
> /root/foo is always an integer in the second example, but not
> in the first.
>
> ht
> --
> Henry S. Thompson, HCRC Language Technology Group,
> University of Edinburgh
> W3C Fellow 1999--2002, part-time member of W3C Team
> 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44)
> 131 650-4440
> Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
> URL: http://www.ltg.ed.ac.uk/~ht/ [mail
> really from me _always_ has this .sig -- mail without it is
> forged spam]
>
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2002, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]