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

Thanks, Michael (again).

I have been back to puzzling over this, and trying slight changes in xsd, trying to make sure I understand what you wrote. I don’t think I do.

The approach I outlined seems to “trick” the tools into generating and validating the artifacts the way I wanted, but it seemed “wrong” hence the original post. I *think* your reply confirms that sense.

It is straight forward enough to promote E1 to a global element in Base, but that does not seem to address the issues. Once I qualify the forms, the element doubles rather than being modified. It may be an error in how I do the restriction. I could promote the E1 and E2 to abstract elements, and create substitution groups, but that fails by eliminating the covariance I am striving for. E1’ and E2’ go together, as do E1’’ and E2’’. E1’ and E2’’ in the same RestrictedType doesn’t work.

I could, in principle, create an approach whereby conforming derivative schemas would create instantiation of the elements, in effect requiring at the top of each conforming derived schema:

<xs:import namespace="urn:inheritance:base" schemaLocation="baseSchema.xsd"/>

<xs:import namespace="urn:inheritance:base" schemaLocation="someDerivation.xsd"/>

<xs:import namespace="urn:inheritance:base" schemaLocation="someOtherDerivation.xsd"/>

And then launch into the definitions. Only E1 and E2 could be defined in ="someDerivation.xsd" and "someOtherDerivation.xsd", leaving more complex definitions and the actual concrete derivatives in their own space. That feels too complex to be satisfying.

Leaving all that aside, it is not clear to me how I would do it using XSD 1.1. How would I?

thanks

"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@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" 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.