Re: [xml-dev] Unqualified forms and Inheritance by Restriction

["Pete Cordell" <petexmldev@codalogic.com>]

In an attempt to redeem myself...

Following on from Michael Kay's comments, when using XSD1.0, the only real 
way to do it is declare your restricted schema to have the same target 
namespace as the Base schema.

I think one way to get around this is to define a 'wrapper' schema and then
xs:include your Base and Restricted namespace within it, e.g.:

<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:include schemaLocation="Base.xsd"/>
    <xs:include schemaLocation="Restricted.xsd"/>
</xs:schema>

then both have:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns="http://www.example.org/Base";
targetNamespace="http://www.example.org/Base";
elementFormDefault="qualified">

Alternatively you could make E1 and E2 as global elements in the Base
namespace, but leave the rest in the Restricted namespace and do:

                <xs:restriction base="base:AType">
                                <xs:sequence>
                                                <xs:element ref="base:E1"/>
                                                <xs:element ref="base:E2"/>
                                </xs:sequence>
                </xs:restriction>

HTH,

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Toby Considine" <Toby.Considine@gmail.com>
To: <xml-dev@lists.xml.org>
Sent: Friday, March 16, 2012 6:01 PM
Subject: RE: [xml-dev] Unqualified forms and Inheritance by Restriction


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:  <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com





From: Michael Kay [mailto:mike@saxonica.com]
Sent: Friday, March 16, 2012 10:53 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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>
"http://www.w3.org/2001/XMLSchema"; xmlns= <VIPRE Anti-phishing found a known 
bad URL in your email message. It was deleted or quarantined, depending on 
your settings, and replaced with this message. The anti-phishing setting is 
located in File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." targetNamespace= <VIPRE Anti-phishing found a known 
bad URL in your email message. It was deleted or quarantined, depending on 
your settings, and replaced with this message. The anti-phishing setting is 
located in File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." 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>
"http://www.w3.org/2001/XMLSchema"; xmlns=
<VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab.> "VIPRE Anti-phishing found a known bad URL in your 
email message. It was deleted or quarantined, depending on your settings, 
and replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab."
xmlns:base= <VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.> "VIPRE Anti-phishing found a 
known bad URL in your email message. It was deleted or quarantined, 
depending on your settings, and replaced with this message. The 
anti-phishing setting is located in File>Settings under the Email Protection 
tab."
targetNamespace= <VIPRE Anti-phishing found a known bad URL in your email 
message. It was deleted or quarantined, depending on your settings, and 
replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." elementFormDefault="qualified">

<xs:import namespace= <VIPRE Anti-phishing found a known bad URL in your 
email message. It was deleted or quarantined, depending on your settings, 
and replaced with this message. The anti-phishing setting is located in 
File>Settings under the Email Protection tab.>
"VIPRE Anti-phishing found a known bad URL in your email message. It was 
deleted or quarantined, depending on your settings, and replaced with this 
message. The anti-phishing setting is located in File>Settings under the 
Email Protection tab." 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:  <mailto:Toby.Considine@fac.unc.edu> Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com