RE: [RESEND] Derivation by restriction

[
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?:
]

My understanding is that this is intended to say that in comparison with
the encouraged GML object type hierarchy, the property type hierarchy is
not necessary in GML, and it may be avoided to prevent from the
complicated issues in schema validation as you suggested, and
difficulties in instance processing caused by the
derivation-by-restriction as there is no compatible concept in either
conventional OO programming languages or relational database theory. 

Lisa
   


-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
On Behalf Of Krzysztof Fink-Finowicki
Sent: Friday, December 11, 2009 5:04 AM
To: xmlschema-dev@w3.org
Subject: 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 17:13:52 UTC