RE: Restrictions and element namespaces

My comments in KLS tags...

-----Original Message-----
From: ht@cogsci.ed.ac.uk [mailto:ht@cogsci.ed.ac.uk]
Sent: Thursday, September 06, 2001 10:43 AM
To: Schwarzhoff, Kelly
Cc: 'www-xml-schema-comments@w3.org'
Subject: Re: Restrictions and element namespaces


"Schwarzhoff, Kelly" <kelly.schwarzhoff@commerceone.com> writes:

> Comments below in KLS tags...
> 
> -----Original Message-----
> From: ht@cogsci.ed.ac.uk [mailto:ht@cogsci.ed.ac.uk]
> Sent: Thursday, September 06, 2001 1:35 AM
> To: Schwarzhoff, Kelly
> Cc: 'www-xml-schema-comments@w3.org'
> Subject: Re: Restrictions and element namespaces
> 
> 
> "Schwarzhoff, Kelly" <kelly.schwarzhoff@commerceone.com> writes:
> 
> > I am writing a few schemas using restrictions features, and there seems
to
> > be an ambiguity w.r.t. what the namespace is of local elements. Consider
a
> > schema:
> > 
> > ===============================
> > <?xml version="1.0"?>
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > targetNamespace="http://localhost/kelly"
> > xmlns:sns="http://localhost/kelly"
> > elementFormDefault="qualified"
> > >
> > 
> > 
> >   <element name="RootTag" type="sns:MainType"/>
> > 
> >   <complexType name="MainType">
> >     <sequence>
> >       <xsd:element name="shipTo" type="sns:ShipType" minOccurs="0" 
> > maxOccurs="unbounded"/>
> >       <xsd:element name="billTo" type="xsd:string" minOccurs="0"/>
> >     </sequence>
> >     <attribute name="currency" type="xsd:string"/>
> >   </complexType>
> > 
> >   <complexType name="ShipType">
> >     <sequence>
> >       <element name="Shipper" type="xsd:string"/>
> >     </sequence>
> >   </complexType>
> > 
> > </schema>
> > =========================
> > 
> > Then, in a seperate namespace, we restrict the root type
> > 
> > =========================
> > <schema xmlns="http://www.w3.org/2001/XMLSchema"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > targetNamespace="http://localhost/two"
> > xmlns:sns="http://localhost/kelly"
> > xmlns:tns="http://localhost/two"
> > elementFormDefault="qualified"
> > >
> > 
> > 
> >   <complexType name="NewShipType">
> >     <complexContent>
> >       <extension base="sns:ShipType">
> >         <sequence>
> >           <element name="City" type="xsd:string"/>
> >         </sequence>
> >       </extension>
> >     </complexContent>
> >   </complexType>
> > 
> >   <complexType name="RMainType">
> >     <complexContent>
> >       <restriction base="sns:MainType">
> >         <sequence>
> >           <xsd:element name="shipTo" type="tns:NewShipType"
minOccurs="0" 
> > maxOccurs="unbounded"/>
> >           <xsd:element name="billTo" type="xsd:string" minOccurs="0"/>
> >         </sequence>
> >       </restriction>
> >     </complexContent>
> >   </complexType>
> > </schema>
> > =========================
> 
> The tns:RMainType definition is broken, for two reasons:
> 
> 1) The sns:MainType definition allows sequences (sns:shipTo*,sns:billTo?).
>    The tns:RMainType definition allows sequences
(tns:shipTo*,tns:billTo?).
>    But renaming of elements is not an allowed part of restriction.
> <KLS>
> That assumes shipTo is now in the tns namespace (or more specifically, the
> namespace tns prefix is bound to). I don't see where the spec says that
one
> way or another. Since I am using restriction, I am really restricting the
> way a previously defined (local) element is used.
> </KLS>

shipTo is not 'now' in the tns namespace -- it's a 'name' of a
<element> with form='qualified' (by inheritance).  The rules for such
an element is that the corresponding element declaration component
takes its [target namespace] from the <element> item's <schema>
ancestor's 'targetNamespace' attribute.  See [1], the description of
properties for when the "<element> element information item has
<complexType> or <group> as an ancestor and the ref [attribute] is
absent"

> 2) Even if you changed to form="unqualified", which would solve _that_ 
>    problem, tns:newShipType is not a restriction of sns:ShipType, it's an 
>    extension, which is not allowed.
> <KLS>
> Where does the spec say it is not allowed? When thinking about it,
> tns:newShipType is really a specific type of sns:ShipType. I.e. you can
use
> tns:newShipType whereever sns:ShipType is defined, but you can't use
> sns:ShipType when tns:newShipType. So, in this sense the fact that the
> restriction uses the extension (tns:newShipType), not the base
> (sns:ShipType), is really restricting which types can be used.
> </KLS>

Corresponding elements in restricted type definitions must themselves
have identical type definitions, or the element in the restriction
must be have a type definition which is a restriction of the
corresponding element's type.  See clause 7 and the NOTE which follows 
of [2].

<KLS>
The note implies, yes, that in restricted complex type content models, local
elements which are redefined can only be restricted.

However, the clause--which is more normative than the note--says quite
another thing. It says, "7 R's {type definition} is validly derived given
{extension, list, union} from B's {type definition} as defined by Type
Derivation OK (Complex) (§3.4.6) or Type Derivation OK (Simple) (§3.14.6),
as appropriate. " Now, if you look at the "Type Derivation OK (Complex)
(3.4.6)" section, it says, "B must be D's {base type definition}". It does
NOT say is must be a restriction, only a base type.

Kelly
</KLS>

ht

[1] http://www.w3.org/TR/xmlschema-1/#declare-element
[2] http://www.w3.org/TR/xmlschema-1/#rcase-NameAndTypeOK
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, 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/

Received on Thursday, 6 September 2001 13:57:29 UTC