Re: [RESEND] Derivation by restriction

This discussion was a long time ago:
http://lists.w3.org/Archives/Public/xmlschema-dev/2002Mar/0219.html

but it seems that I've reached the same problem.

Opposite to Roger L. Costello statement, Best Practices from xFront
*advises* parallel substitution group element hierarchies in elements and
element containers as well. See "Implementing Substitution Group Element
Hierarchies" in:
http://www.xfront.com/ElementHierarchy.html

I've seen in "OpenGISR Geography Markup Language (GML) Encoding Standard"
version 3.2.1 opened possibility for this, e.g. in 21.4.2.2 "User-defined
geometry property types" we have:
"A geometry property type may be a restriction of gml:GeometryPropertyType,
but this is not a requirement."

My question is - why it is not a practice in GML 3.2.1?:

In GML, we have AbstractGeometry element:

<element name="AbstractGeometry" type="gml:AbstractGeometryType"
abstract="true" substitutionGroup="gml:AbstractGML"/>

and "generic" Property type (container) like below:

<complexType name="GeometryPropertyType">
    <sequence minOccurs="0">
        <element ref="gml:AbstractGeometry"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
    <attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>

Then there are *lot of* concrete geometry types, extending
AbstractGeometryType, and associated geometry elements, belonging to
substitutionGroup of AbstractGeometry. e.g. Point (indirect derivation and
obsolete content simplified for brevity):

<complexType name="PointType">
    <complexContent>
        <extension base="gml:AbstractGeometryType">
            <sequence>
                <element ref="gml:pos"/>
            </sequence>
        </extension>
    </complexContent>
</complexType>

<element name="Point" type="gml:PointType"
substitutionGroup="gml:AbstractGeometry"/>

All these Point, Curve, Surface, ..., PointArray, CurveArray, SurfaceArray,
... have their own Property (container) types defined but not within any
hierarchy, only "following the same pattern", like below:

<complexType name="PointPropertyType">
    <sequence minOccurs="0">
        <element ref="gml:Point"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
    <attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>

My question is: What's wrong with defining all similar containers using
"infamous" derivation by restriction, like below:

<complexType name="PointPropertyType">
    <complexContent>
        <restriction base="gml:GeometryPropertyType">
            <sequence>
                <element ref="gml:Point"/>
            </sequence>
        </restriction>
    </complexContent>
</complexType>

Is it only due to troubles with MSXML validation (see
http://markmail.org/message/fotntmddcmmwhkoc) ?

Element gml:Point is in substitution group of gml:AbstractGeometry, so can
be used here, isn't it? Ot it is the problem that PointType is EXTENSION of 
AbstractGeometryType, while I suggest to define PointPropertyType as
RESTRICTION of GeometryPropertyType? Best Practices paper cited above
doesn't mention about this.

With my suggestion, at least two benefits can be seen:

- after changing or extending usage of attributeGroup's
(gml:AssociationAttributeGroup, gml:OwnershipAttributeGroup) it wouldn't be
necessary to "follow the same pattern" in all duplicated container
definitions;

- it would be possible to define some flexible content models allowing
Feature to have *any* geometryProperty, replaceable by concrete
pointProperty, curveProperty and so on;

This flexibility would be specifically convenient when creating layered
schemas - flexible generic one with "templated", and concretized specific
ones with restricted content.

Please explain me where I'm wrong.

Received on Friday, 11 December 2009 13:04:35 UTC