[Geotools-devel] Identity, containment, and modeling power

[Gabriel <gr...@ax...>]

Sorry by throwing in more burden to the discussion, but it might worth the=
=20
effort.

=46rom GML 3.1.1 spec, page 23: (paragraph numbers are mine)


"(1) A GML object is an XML element of a type derived directly or indirectl=
y=20
from AbstractGMLType. From this derivation, a GML object may have a gml:id=
=20
attribute.

(2) A GML property may not be derived from AbstractGMLType, may not have a=
=20
gml:id attribute, or any other attribute of XML type ID.

(3) An element is a GML property if and only if it is a child element of a =
GML=20
object.

(4) No GML object may appear as the immediate child of a GML object.

(5) Consequently, no element may be both a GML object and a GML property.

(6) NOTE        In this version of GML, the use of additional XML attribute=
s=20
in a GML application schema is discouraged."


(1) Identity: aparently our type system may be able of dealing with identit=
y=20
beyond Feature. Any complex type that you define may inherit from=20
AbstractGMLType or not. If it does, it _may_ have identity, as well as=20
metadataProperty, description and name:

//you'll find a better name, my english is getting to its limit
interface IdentityComplex extends Complex{
	String getID();
	Map<String, Object> getMetadataProperty();
	List<String> getName(); //yes, it's 0..N =20
}

interface Feature extends IdentityComplex{
	CoordinateReferenceSystem getCRS();
	Envelope getBounds();
	FeatureType getType();
	GeometryAttribute getDefault();
}

interface GeometryAttribute extends IdentityComplex{
 ...
}


(2): that's Attribute and Complex ( "may" means its a recommendation?)

(4): that's where the gml:AssociationType pattern comes from. Currently, wh=
en=20
we encode a GeometryAttribute to GML, we respect that rule just because we=
=20
already know how geometries should be encoded. Adding IdentityComplex makes=
=20
it more explicit and allows for user defined types to derive from=20
AbstractGMLType

(6) that's consistent with the Object/property rule.

(5) the following is a real world example:

<sco:wq_plus gml:id=3D"_41010901">
    <sco:sitename>BALRANALD WEIR</sco:sitename>
    <sco:anzlic_no>ANZNS0359100023</sco:anzlic_no>
    <sco:location>
      <gml:Point  srsName=3D"http://www.opengis.net/gml/srs/epsg.xml#4283">
        <gml:pos>22 143.53399658</gml:pos>
      </gml:Point>
    </sco:location>
    <sco:measurement gml:id=3D"_16JAN94002001002003000000">
      <sco:determinand_description>16/JAN/94</sco:determinand_description>
      <sco:result>Turbidity</sco:result>
    </sco:measurement>
    <sco:measurement gml:id=3D"_24JAN94002001002003000000">
      <sco:determinand_description>24/JAN/94</sco:determinand_description>
      <sco:result>Turbidity</sco:result>
    </sco:measurement>
    <sco:project_no>RWWQ0004</sco:project_no>
  </sco:wq_plus>

Given (5), <sco:measurement> is apparently wrong, since it is both a proper=
ty=20
and an IdentityComplex (its type derives from AbstractGMLType, or its badly=
=20
defined, because of (1) and (6).


So that's the proposal, adding a identity capable complex attribute, since =
its=20
clear that not only features may have id, there are plenty of them in the G=
ML=20
spec (for example, Geometry), and a user may be able of defining its own=20
complex type with identity.

comments?

Gabriel.