- From: Jeff Lowery <jlowery@scenicsoft.com>
- Date: Sat, 5 Jan 2002 13:31:19 -0800
- To: "'Martin Bernauer '" <bernauer@dke.uni-linz.ac.at>, "'Achille Fokoue '" <achille@us.ibm.com>, "'xmlschema-dev@w3.org '" <xmlschema-dev@w3.org>
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