This seems to argue that the tools that “accept” what I am doing now, do so in error. Which I had an uneasy feeling they did.
>>Because the element declaration isn't global, the only way you can replace it with a different element declaration of the same name is by putting that declaration in a schema >>document whose target namespace is {Base}.
How would I do this? I tried several variants on
<xs:restriction base="base:AType">
<xs:sequence>
<xs:element name="base:E1" type="xs:string" fixed="foo"/>
<xs:element name="base:E2">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="fie"/>
<xs:enumeration value="foe"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:restriction>
And they failed the same, even when I went so far as to make E1 and E2 root elements in base. At this point I am trying to create valid XML by the infinite monkey approach.
http://en.wikipedia.org/wiki/Infinite_monkey_theorem
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
| | Email: Toby.Considine@g... Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com |
From: Michael Kay [mailto:mike@s...]
Sent: Friday, March 16, 2012 10:53 AM
To: xml-dev@l...
Subject: Re: Unqualified forms and Inheritance by Restriction
The issue here is that if element {Base}E1 is mandatory in the base type, it's not good enough to have an element {Restricted}E1 in its place in the derived type: the elements must have the same name.
Because the element declaration isn't global, the only way you can replace it with a different element declaration of the same name is by putting that declaration in a schema document whose target namespace is {Base}.
XSD 1.1 solves this by allowing you to specify targetNamespace as an attribute on a local element declaration. In 1.0, though, there's no alternative to putting the restricted type in a schema document for the {Base} namespace -- even if this means tresspassing on someone else's namespace.
Michael Kay
Saxonica
On 16/03/2012 13:47, Toby Considine wrote:
I have a family of schemas for energy markets that are derived from a root abstract schema. In most cases, the derived types extend the abstract types by adding additional elements. This inheritance by addition is straight-forward.
For one key abstract type, I use inheritance by restriction. Derived types must have all the elements of the root type, but they may be restricted to a few enumerated values. Consider the following, simplified and stripped down:
Root Schema:
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns=http://www.example.org/Base targetNamespace=http://www.example.org/Base elementFormDefault="qualified">
<xs:element name="A" type="AType"/>
<xs:complexType name="AType" abstract="true">
<xs:sequence>
<xs:element name="E1" type="xs:string"/>
<xs:element name="E2" type="xs:string" />
</xs:sequence>
</xs:complexType>
Derivative schema
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns=http://www.example.org/Restriction xmlns:base=http://www.example.org/Base targetNamespace=http://www.example.org/Restriction elementFormDefault="qualified">
<xs:import namespace=http://www.example.org/Base schemaLocation="Base.xsd"/>
<xs:element name="ARestricted" type="ARestrictedType"/>
<xs:complexType name="ARestrictedType" abstract="false">
<xs:complexContent>
<xs:restriction base="base:AType">
<xs:sequence>
<xs:element name="E1" type="xs:string" fixed="foo"/>
<xs:element name="E2">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="fie"/>
<xs:enumeration value="foe"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
The derivative schema is invalid. In particular, when processed, each element in ARestricted generates the following error: "rcase-NameAndTypeOK.1: The declarations' {name}s and {target namespace}s are not the same: restriction element is <xs:element name="itemDescription"> and base element is <xs:element name="itemDescription">."
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#rcase-NameAndTypeOK
I can avoid the error if I change each of the schemas from elementFormDefault="qualified" to elementFormDefault="unqualified". The derived schema now validates using XML Spy and Liquid XML Studio. When I use the Liquid Technologies code generation tool to create software objects, the objects generate XML that looks like what I want.
Here’s the question:
Should I be looking for some side effect of switching these schemas from qualified to unqualified? Is there some hidden problem I will come upon if I require conforming schemas to be unqualified? I generally prefer “qualified” for the esthetic reason that I like to see explicit type derivations (prefices) in the schema. I do not have a feel for what else may be affected.
Thanks
tc
"You can cut all the flowers but you cannot keep spring from coming."
-Pablo Neruda.
Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
| | Email: Toby.Considine@g... Phone: (919)619-2104 http://www.tcnine.com/ blog: http://www.NewDaedalus.com |