Re: [Geotools-devel] Why we don't want ft to extend at.

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

The following is my rationale for FeatureType not extending AttributeType:

As you will see, declaring a FeatureType attribute to be of another=20
=46eatureType type is bad GML practice. Instead, what you should do is to=20
follow the GML association type pattern, by declaring a container for your=
=20
nested featuretype.
That container is what will allow you to remotelly reference the nested=20
features with xlink:href, as well as provide multiplicity. The nested=20
=46eatureType is then reused, as you expect, and untouched.

Consider the following example:

<complexType name=3D"RiverType">
=A0 =A0 <complexContent>
=A0 =A0 =A0 <extension base=3D"gml:AbstractFeatureType">
=A0 =A0 =A0 =A0 <sequence>
=A0 =A0 =A0 =A0 =A0 <element ref=3D"gml:centerLineOf"/>
=A0 =A0 =A0 =A0 </sequence>
=A0 =A0 =A0 </extension>
=A0 =A0 </complexContent>
 </complexType>

RiverType IS the FeatureType we want to reuse:

<complexType name=3D"Basin">
=A0 =A0 <complexContent>
=A0 =A0 =A0 <extension base=3D"gml:AbstractFeatureType">
=A0 =A0 =A0 =A0 <sequence>
=A0 =A0 =A0 =A0 =A0 <element minOccurs=3D"1" ref=3D"ex:River"/>
=A0 =A0 =A0 =A0 </sequence>
=A0 =A0 =A0 </extension>
=A0 =A0 </complexContent>
</complexType>

WRONG. It should be:

<xs:element name=3D"Basin" type=3D"test:BasinType"=20
substitutionGroup=3D"gml:_Feature"/>
  <xs:complexType name=3D"BasinType">
    <xs:complexContent>
      <xs:extension base=3D"gml:AbstractFeatureType">
        <xs:sequence>
          <xs:element name=3D"riverProperty">
           <xs:complexType>
            <xs:complexContent>
             <xs:restriction base=3D"gml:FeaturePropertyType">
              <xs:sequence minOccurs=3D"0">
               <xs:element ref=3D"test:River"/>
              </xs:sequence>
             </xs:restriction>
            </xs:complexContent>
           </xs:complexType>
          </xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

Note de definition of riverProperty element, restricting=20
gml:FeaturePropertyType to contain only River instances.

Now suppose you have a Basin db table where one of its columns contains a=20
River feature instance. That model is consistent with the association type=
=20
(riverProperty is the name of the column and the actual River Feature its=20
value)
That's exactly what is modeled by:

interface FeatureAttributeType extends ComplexAttributeType{
 FeatureType getFeatureType();
}

The other, though valid XMLSchema, is non valid GML.

Gabriel.

On Thursday 25 August 2005 02:33, Justin Deoliveira wrote:
> Jody and myself walked through Ian's example and came up with the
> following summary. Jody will reiterate tommorow.
>
> With the seperation of schema/validation from type, the gml example from
> before looks the attached diagram.
>
> The thing to note from the diagram is that since the schema information
> is seperated out, the river feature type just becomes another complex
> attribute type, and becomes available for reuse.
>
> Justin
>
> Jody Garnett wrote:
> > Chris Holmes wrote:
> >> From IanS - this argument definitely persuaded me.  Sorry I haven't
> >> sounded in earlier, but yeah, don't do ft extends at.
> >
> > So if I can sum up we have a conflict with our AttributeType information
> > we use for validation (such as minOccurs and maxOccurs) and the idea of
> > a FeatureType extending CompexType.
> >
> > In short we would like to reuse our FeatureType in a diferent context.
> > We would like to define the FeatureType in terms of its contents, and
> > then when it comes time to use that FeatureType as a child in a feature
> > collection, or as an element in a complex type we don't want to get
> > confused.
> >
> > Aside: Strangly enough this is exactly where Gabriel is stuck, only he
> > is wanting to reuse SimpleAttributeType that provide the mappings from
> > XMLSchema. His first cut was as a enumeration that would need to be
> > consulted. It appears to me to be a poor case of code reuse, the
> > enumeration would be a close set and client code would have to navigate
> > to it.  As an impelmentation detail (with the enumeration used as a
> > directory of facets it may work), or we can break out an
> > Attribtue.getSuper method.
> >
> > Idea:  We have split out schema information (that is information that
> > can only produce a validation error, not objects) into a separate
> > construct. Min / Max Occurs really does fall into this category.
> >
> > MinOccurs / MaxOccurs is schema information (and not type information).
> > I will try and walk through IanS's examples in the next email.
> >
> > Jody
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Geotools-devel mailing list
> > Geo...@li...
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel