RE: [SQC is right] Derivation by Restriction and Namespaces - SQC Bug?

First of all: good catch, Achille!

Second, let me see if I can put it more simply:

When elementFormDefault is "unqualified" all local elements (ones that are
not declared globally in the schema) do not have a namespace qualification
(Henry says they're "associated" with the parent's namespace, but not "in"
the parent's namespace). One consequence of this is that if your instance
document has a default namespace, your local elements would be qualified,
and therefore invalid according to the schema definition (unless you "turn
off" the default namespace by declaring xmlns="" in each local element
instances).

When the schema has elementFormDefault="qualified", then all local element
declarations belong to (are actually "in") the targetNamespace of the
schema. That means that they either have to be namespace prefixed, or have a
defaultNamespace equivalent to the targetNamespace in the schema.

Now, take your <any> element. With elementFormDefault="qualified" the
wildcard allows any local element whose namespace matches the
targetNamespace. In your derived type, you changed namespaces, and then
tried to restrict the base type by declaring an element from a different
namespace. But that element was never allowed by the any wildcard to begin
with, so you actually wound up with an extension rather than a restriction.

I don't know if that deepened your understanding, but I hope it was a little
more clearly put. 

-----Original Message-----
From: Martin Bernauer
To: Achille Fokoue; xmlschema-dev@w3.org
Sent: 1/3/02 8:25 AM
Subject: Re: [SQC is right] Derivation by Restriction and Namespaces - SQC
Bug?

Thanks a lot! That definitely helped (you were right, I had
elementFormDefault="qualified")! I think I understand it now.

To summarize, is it right if I state the following (when using schemas
showing
elementFormDefault="qualified")?
    Given a base type b:BaseType that defines a content model comprising
an
element b:someElement of b:someType, it is not possible to derive a new
complex
type r:RestrictedType from b:BaseType by restriction that changes the
type of
b:someElement to type r:someRestrictedType (that was derived by
restriction from
b:someType) WITHOUT "touching" namespace b? (by touching I mean defining
new
types that belong to namespace b, because when I define a new
intermediate type
in namespace b I can think of an rather awkward way to achieve the
desired
inheritance mentioned before). The only way to achieve the desired
inheritance
without touching namespace "b" is to put "someElement" into NO
namespace.

Practically this seems to mean that if someone defines a schema (i.e.,
namespace), e.g. for cars, where each car features a motor of a certain
type, I
can't define my own namespace defining a "restricted" car featuring a
"restricted" motor without modifying the otherones namespace (keeping in
mind,
that the otherone used elementFormDefault="qualified"). I feel a little
bit
confused...

Thanks again,
Martin


----- Original Message -----
From: "Achille Fokoue" <achille@us.ibm.com>
To: <xmlschema-dev@w3.org>; <bernauer@dke.uni-linz.ac.at>
Cc: <jlowery@scenicsoft.com>; "Bob Schloss" <rschloss@us.ibm.com>
Sent: Thursday, January 03, 2002 4:20 PM
Subject: Re: [SQC is right] Derivation by Restriction and Namespaces -
SQC Bug?


>
>
> The latest version of SQC is 1.2.1.003 available at
> http://www.alphaworks.ibm.com/tech/xmlsqc.
>
> I think SQC is right.
>
> Martin, your examples test1a.xsd and test1b.xsd  start with <xs:schema
> targetNamespace="http://test1a" xmlns:t1a="http://test1a" ...> and
> <xs:schema targetNamespace="http://test1b" xmlns:t1a="http://test1a"
> xmlns:t1b="http://test1b" ...>. Unfortunately, you did not give us the
> values  all the attributes of <xs:schema>.  Among all its possible
> attributes, "elementFormDefault" is particularly important to
understand
> why SQC complains about your schema.
>
>  If  your  two schemas  have  elementFormDefault="unqualified" (it is
the
> default ), then SQC will not report any error. However, if at least
one of
> the two schemas specifies elementFormDefault="qualified" then it means
that
> all local elements in your schema file are qualified and have the same
> namespace as the schema target namespace. Since the two schemas do not
have
> the same target namespace,  the local elements  <xs:element
name="entry"
> type="t1a:BasicEntry"/>  and <xs:element name="entry" type
> ="t1b:RestrictedEntry"/>, although they have the same name, are
different
> because they have different namespaces. Hence,  the content model of
> RestrictedList is not a valid  restriction of the content model of
> BasicList. That's why SQC reports an error.
>
>
>
> I hope this helps,
>
> Achille Fokoue.
>
> IBM T.J. Watson Research Center
>
> xschema@us.ibm.com
>
>
>
>
>
>
>
> Message-ID:
> <3549BAFD79A7D411A1CF00508B62B5BC0124B991@exchange-us.scenicsoft.com>
> From: Jeff Lowery <jlowery@scenicsoft.com>
> To: "'Martin Bernauer'" <bernauer@dke.uni-linz.ac.at>,
xmlschema-dev@w3.org
> Date: Wed, 2 Jan 2002 16:59:27 -0800
> Subject: RE: Derivation by Restriction and Namespaces - SQC Bug?
>
> Shouldn't get any error.
>
> When I run the example through SQC (version 1.2.004), I don't get the
error
> you're seeing. Are you running a newer or older version?
>
> > -----Original Message-----
> > From: Martin Bernauer [mailto:bernauer@dke.uni-linz.ac.at]
> > Sent: Wednesday, January 02, 2002 6:27 AM
> > To: xmlschema-dev@w3.org
> > Subject: Derivation by Restriction and Namespaces - SQC Bug?
> >
> >
> > I have troubles concerning derivation by restriction
> > concerning namespaces. When
> > I derive a new type by restriction and want to put it in
> > another namespace than
> > the one of its base type, SQC from alphaworks [1] detects an error.
> >
> > To illustrate this consider the following example, depicting
> > two schemas. Schema
> > test1a.xsd defines a "BasicEntry" Type and a "BasicList"
> > Type, the contents
> > model of the latter type comprises "entry" elements of type
> > BasicEntry.
> >
> > ----------[begin schema test1a.xsd ]----------
> > <xs:schema targetNamespace="http://test1a"
> > xmlns:t1a="http://test1a" ...>
> >   <xs:complexType name="BasicEntry">
> >     <xs:sequence>
> >       <xs:any/>
> >     </xs:sequence>
> >   </xs:complexType>
> >   <xs:complexType name="BasicList">
> >     <xs:sequence>
> >       <xs:element name="entry" type="t1a:BasicEntry"/>
> >     </xs:sequence>
> >   </xs:complexType>
> > </xs:schema>
> > ----------[end schema test1a.xsd ]----------
> >
> > A second schema, test1b.xsd, derives a new type "RestrictedEntry"
from
> > BasicEntry by restriction and a new type "RestrictedList"
> > from BasicList. Notice
> > that the namespace of RestrictedList is http://test1b, while
> > the namespace of
> > BasicList is http://test1a.
> >
> > ----------[begin schema test1b.xsd ]----------
> > <xs:schema targetNamespace="http://test1b" xmlns:t1a="http://test1a"
> > xmlns:t1b="http://test1b" ...>
> >   <xs:import namespace="http://test1a" schemaLocation="test1a.xsd"/>
> >   <xs:complexType name="RestrictedEntry">
> >     <xs:complexContent>
> >       <xs:restriction base="t1a:BasicEntry">
> >         <xs:sequence>
> >           <xs:element name="restrictingElement" type="xs:string"/>
> >         </xs:sequence>
> >       </xs:restriction>
> >     </xs:complexContent>
> >   </xs:complexType>
> >   <xs:complexType name="RestrictedList">
> >     <xs:complexContent>
> >       <xs:restriction base="t1a:BasicList">
> >         <xs:sequence>
> >           <xs:element name="entry" type="t1b:RestrictedEntry"/>
> >         </xs:sequence>
> >       </xs:restriction>
> >     </xs:complexContent>
> >   </xs:complexType>
> > </xs:schema>
> > ----------[end schema test1b.xsd ]----------
> >
> > When validating test1b.xsd, SQC throws an error reporting
> > that the contents
> > model of RestrictedList is not a restriction of BasicList.
> >
> > However, when having all (four) complex type definitions in
> > the same namespace,
> > SQC accepts the schemas. Since the restrictions themselves
> > seem to be valid
> > irrespective of the namespaces this seems to be a bug of SQC
> > for me. Or is the
> > restriction by itself invalid? Any comments on this?
> >
> > Btw XSV (version 2001/11/29) validates test1b.xsd without
> > reporting any
> > problems.
> >
> > Regards, Martin
> >
> > [1] http://www.alphaworks.ibm.com/tech/xmlsqc
> >
> > ps: I wasn't able to post this to the SQC discussion forum,
> > sorry for any
> > inconvienience my posting here may cause, nevertheless it's
> > also an XML Schema
> > specific question.
> >
>
>

Received on Saturday, 5 January 2002 16:32:44 UTC