Rick,

Le jeudi 06 juillet 2006 16:57 +1000, Rick Jelliffe a :
Lots of good points.

For the issue of supertype/subtype/inheritance, there are two aspects.
is whether the constraints can be expressed: and, indeed, the same
constraints can be expressed and RELAX NG et al is more powerful than XSD

The second is whether constraints can be modeled using inheritance
relationships. You are right that RELAX NG does not have any facilities
for this (e.g. it has a facility called combine that can be used to do
the same kind of thing that XSD substution groups does, but it is not a
type-based mechanism.)

My posts are basically an angle brackets adorned version of these two
statements :) but I also wanted to show that this would be quite easy to
represent with annotations.

Le jeudi 06 juillet 2006 08:48 +0200, Eric van der Vlist a :
ooops Just found out how substitution groups can be better translated
in RELAX NG just after having pressed the send button.

I have consolidated these two posts in my blog:
%28continued%29.item

Eric

ooops Just found out how substitution groups can be better translated
in RELAX NG just after having pressed the send button. What I have
written would work, but here is a better way to express substitution
groups.

Compact syntax:

Head = element Head { BaseType }
Head |= element Restricted { RestrictedType }
Head |= element Extended { ExtendedType }
start = element Root { Head }

XML Syntax:

<define name="Head">
<element name="Head">
<ref name="BaseType"/>
</element>
</define>
<define name="Head" combine="choice">
<element name="Restricted">
<ref name="RestrictedType"/>
</element>
</define>
<define name="Head" combine="choice">
<element name="Extended">
<ref name="ExtendedType"/>
</element>
</define>
<start>
<element name="Root">
<ref name="Head"/>
</element>
</start>

Explanation;

The first definition of the Head element is the definition of the
substitution group head and each of the following ones add a new element
as an option.

I think that this is near enough from W3C XML Schema substitution group
that it doesn't require to be marked by an annotation (tools could be
clever enough to detect this pattern) but an annotation could be added
(like I have shown in the previous mail) to make that more explicit.

This is also the case of derivation by extensions in which I had added
no annotation but could also carry one.

Eric

Jack,

Le mercredi 05 juillet 2006 20:26 -0400, Jack Lindsey a :
Rick:

However, I think I am correct in saying that, while Relax NG can
import W3C data types, neither it nor any other DSDL module supports
inheritance in data structures, i.e. the equivalent of WXS
substitution groups with complex type derivation by extension. This
may seem like the ultimate expression of gentrification [1], but I
fear that, unless you have any plans for an optional module in this
area, that alone could rule you out as a mainstream contender, because
these days inheritance seems to be ubiquitous in data modelling of all
kinds, call it supertype-subtype, generalization-specialization or
class hierarchy, e.g.
- Dave Hay's patterns
- Java-fueled UML everywhere you turn
- Len Silverston's Party Model showing up everywhere, including UMM
ebXML Core Components
- the ebXML Registry Information Model itself
- AGIS extensions
- CPSIN, the Canadian equivalent of the GJXDM [2]

And JAXB or better still XMLBeans can effectively generate Java class
hierarchies that exploit the inheritance features of WXS schemas.

RELAX NG (and DSDL in general) focuses on validation and, as far as
validation only is concerned, RELAX NG provides pattern combination
mechanisms that are equivalent to W3C XML Schema derivation and
substitution groups.

Let's see on a simple example

We have the following base type:

W3C XML Schema:

<xs:complexType name="BaseType">
<xs:sequence>
<xs:element name="FirstName" type="xs:token"/>
<xs:element name="LastName" type="xs:token"/>
<xs:element name="Mail" type="xs:token" ="0"/>
</xs:sequence>
</xs:complexType>

Equivalent RELAX NG (compact syntax):

BaseType =
element FirstName { xsd:token },
element LastName { xsd:token },
element Mail { xsd:token }?

Equivalent RELAX NG (XML syntax):

<define name="BaseType">
<element name="FirstName">
<data type="token"/>
</element>
<element name="LastName">
<data type="token"/>
</element>
<optional>
<element name="Mail">
<data type="token"/>
</element>
</optional>
</define>

1) Derivation by extension:

W3C XML Schema:

<xs:complexType name="ExtendedType">
<xs:complexContent>
<xs:extension base="BaseType">
<xs:sequence>
<xs:element name="Password" type="xs:token"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

Equivalent RELAX NG (compact syntax):

ExtendedType =
BaseType,
element Password { xsd:token }

Equivalent RELAX NG (XML syntax):

<define name="ExtendedType">
<ref name="BaseType"/>
<element name="Password">
<data type="token"/>
</element>
</define>

2) Derivation by restriction:

W3C XML Schema:

<xs:complexType name="RestrictedType">
<xs:complexContent>
<xs:restriction base="BaseType">
<xs:sequence>
<xs:element name="FirstName" type="xs:token"/>
<xs:element name="LastName" type="xs:token"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

Equivalent RELAX NG (compact syntax):

RestrictedType =
element FirstName { xsd:token },
element LastName { xsd:token }

Equivalent RELAX NG (XML syntax):

<define name="RestrictedType">
<element name="FirstName">
<data type="token"/>
</element>
<element name="LastName">
<data type="token"/>
</element>
</define>

3) Substitution group:

W3C XML Schema:

<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element ref="Head"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="Head" type="BaseType"/>

<xs:element name="Restricted" type="RestrictedType" substitutionGroup="Head"/>

<xs:element name="Extended" type="ExtendedType" substitutionGroup="Head"/>

Equivalent RELAX NG (compact syntax):

Head = element Head { BaseType }
Restricted = element Restricted { RestrictedType }
Extended = element Extended { ExtendedType }
start = element Root { Head | Restricted | Extended }

Equivalent RELAX NG (XML syntax):

<define name="Head">
<element name="Head">
<ref name="BaseType"/>
</element>
</define>
<define name="Restricted">
<element name="Restricted">
<ref name="RestrictedType"/>
</element>
</define>
<define name="Extended">
<element name="Extended">
<ref name="ExtendedType"/>
</element>
</define>
<start>
<element name="Root">
<choice>
<ref name="Head"/>
<ref name="Restricted"/>
<ref name="Extended"/>
</choice>
</element>
</start>

So what?

These schemas are equivalent (*) AS FAR AS VALIDATIN IS
CNCERNED

What is missing from the RELAX NG schemas are the declarations of
intention that RestrictedType is a restriction of BaseType and that
Head, Restricted and Extended belong to the same substitution group.

These notions have been left out of RELAX NG because, like mentioned in
one of my previous mails, RELAX NG has made no exception and has
rejected any feature that isn't related to validation and, again, these
schemas validate the same set of documents (*).

If these notions are important for an application, it should be noted
they are very easy to add through annotations, for instance:

namespace oo = ""

BaseType =
element FirstName { xsd:token },
element LastName { xsd:token },
element Mail { xsd:token }?

ExtendedType =
BaseType,
element Password { xsd:token }

[ oo:restricts = "BaseType" ]
RestrictedType =
element FirstName { xsd:token },
element LastName { xsd:token }
Head = element Head { BaseType }

[ oo:substitutionGroup = "Head" ]
Restricted = element Restricted { RestrictedType }

[ oo:substitutionGroup = "Head" ]
Extended = element Extended { ExtendedType }

start = element Root { Head | Restricted | Extended }

in the XML Syntax:

<define name="RestrictedType" oo:restricts="BaseType">
<element name="FirstName">
<data type="token"/>
</element>
<element name="LastName">
<data type="token"/>
</element>
</define>

<define name="Head">
<element name="Head">
<ref name="BaseType"/>
</element>
</define>
<define name="Restricted" oo:substitutionGroup="Head">
<element name="Restricted">
<ref name="RestrictedType"/>
</element>
</define>
<define name="Extended" oo:substitutionGroup="Head">
<element name="Extended">
<ref name="ExtendedType"/>
</element>
</define>
<start>
<element name="Root">
<choice>
<ref name="Head"/>
<ref name="Restricted"/>
<ref name="Extended"/>
</choice>
</element>
</start>

The first annotation (oo:restricts = "BaseType") is a declaration that
RestrictedType must be considered as a restriction of BaseType. As any
annotation, it would be ignored by RELAX NG processors, but could be
enforced by a tool that would check that this represents a real
restriction of its base type (a number of papers have been published
with algorithms to do so).

The second annotations oo:substitutionGroup="Head" are declarations that
Head, Restricted and Extend belong to the same substitution group. In
this example they are redundant with the choice between the three
elements from the substitution group but you could also define the Root
element as:

start = element Root { Head }

or

<start>
<element name="Root">
<ref name="Head"/>
</element>
</start>

and write a XSLT transformation that would process the
oo:substitutionGroup annotations to replace references to Head by
choices. The downside is that the schema before expansion would validate
a different set on instances.

These are only two examples of how annotations can be used to facilitate
the use of RELAX NG for modeling purposes. These two examples mimic W3C
XML Schema features, but annotations are more powerful than there is no
reason to limit their use to what is supported by W3C XML Schema.

Annotations are being more and more widely used in programming languages
and I think that for the same reasons we have a lot to gain by using
them in XML schema languages as well.

Eric

(*) The W3C XML Schema schemas and RELAX NG schemas are not strictly
equivalent in that the RELAX NG schemas do not allow xsi attributes.

Le samedi 08 juillet 2006 09:51 -0400, Jack Lindsey a :

Rick & Eric:

Thank you for your thoughtful and detailed replies.

Your welcome, the technical part of this thread has been a pleasure a I
claim full responsibility for having falling in the trap of engaging the
other part

Time to dig deeper. Sounds like applying Eric's techniques to a Relax
NG version of CPSIN would be a valuable exercise.

Let us know if you ever do this exercise!

Thanks,

Eric