XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Unqualified forms and Inheritance by Restriction

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@gmail.com
Phone: (919)619-2104

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS