[Java-collab] Re: Enums and Switch Statements; ID and URN Resolvers; attached properties

[Markus Schneider]

Hello again,

Jody Garnett wrote:

> When defining these Enums it would be nice to load them up with
> additional information to help with encoding / decoding using
> annotations or otherwise. I hate writing switch statements in order to
> "lookup" gml mapping element names; when that is kind of our starting
> point.
> 
>>>> - #getId() / #setId(). As ids are very integral to GML, I provided
>>>> methods for working with the identifier.
>>>
>>> We have been forced to make up or own Identifier - in response to
>>> GMLObjectIdentifier in order to handle namespace issues. Will a simple
>>> string be sufficient here?
>>
>> Interesting. Can you elaborate why a string does not suffice here? In
>> GML, they are just defined as XML IDs, so the only
>> restriction is that they must match the NCName production rule (and
>> are unique in a document).
> 
> I did not follow this development completely;  I think it was more
> related to the WFS getGMLObject method or something? Basically the idea
> of having a unqiue identifier that would last for more then a single
> document.
> 
> Ben's crew has done some magic with a URN resolver or something that
> allows them to negotiate the difference between IDs in a single document
> and a subsequent request for more information. I did not pretend to keep
> up with their work so we may need to ask him for details.

IMHO, the id resolving stuff can also be handled externally, so I would suggest to keep it as a string until a general
use-case turns up that requires it to be something else.

>>>> - #getAttachedProperties() / #setAttachedProperties(...) for coping
>>>> with
>>>> the GML standard properties that each GML geometry object allows for
>>>> (e.g. multiple gml:metaDataProperty elements, gml:name and
>>>> gml:description properties).
>>>
>>> Commented above about lazy creation; I would consider leaving this as
>>> an implementation details (ie the creation of an internal Properties
>>> object and/or Map) and adding methods for getName(), getDescription()
>>> etc... although it depends on how many of these we expect to ahve?
>>
>> Just would like to throw in that we should avoid to make this too GML
>> (and especially GML-version) centric.
> 
> Oh - I thought we were making this specific to GML (from the IRC meeting).

Well, you're right. As I understand it, we want our model to be compatible with all GML geometry types and to allow a
faithful representation. But then again, it also has to be a sensible abstraction of GML, as we need to be able to
represent ShapeFile, WKT or other geometry sources using our model as well. And for these cases, we don't provide the
GML standard properties, like gml:metaDataProperty. Also, GML 2 allows a slightly different set of these properties (and
maybe GML 3.3 could as well). This is why I would suggest not to cling too close to GML 3.1/3.2 here. Of course it must
still be possible to hold all the information that may come with a GML 3.1 geometry element. BTW, actually I know no one
that actually uses them besides some CITE tests.

> In any case can I ask if "attached properties" is part of GML; or is it
> just a scratch pad for extra information associated with a geometry?

At the moment, it's rather a scratchpad that also allows some kind of extensibility. I would favor to create a
comprehensive interface at some point that represents the contents of the GML standard properties in a version agnostic
manner.

Best regards,
Markus

-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/java-collab/attachments/20090820/896f36b9/signature.bin