> I agree. But the "real one" is the in-memory (OO) version, defined by both
> OGC and ISO. GML is a particular encoding of this OO model, and it
> disallows many things allowed by the XML Schema in order to conform to the
> OO schemas defined elsewhere ('107, '108, '110, '111...). It also contains
> a standard way of mapping the OO model (which _is_ the reference) to XML
> schema. It also lists what rules need to be followed in order to make a
> reverse mapping possible.
>
> One cannot simply validate a document against the GML schemas and call it
> "GML". THere are many ways to violate the GML spec which cannot be
> expressed in XML Schema. However, I fear that this is what many people do,
> if they even bother to do this much.
>
>
I agree with this too. The implication is that you cant necessarily read
the GML schema and get the info you need.
This is why I've been proposing the type-injection where GML elements
can get mapped to pluggable object type libraries - for example ISO19115
type implementations.
Also, people could inject behaviours for objects even where there is no
schema definition.
>> The GeoAPI implementation is derived from the ISO definitions, and we
>> should keep it clean to avoid inconsistencies and extra documentation
>> burden if we choose to redefine it.
>>
>
> Yes and no. The GeoAPI definition is in a no-man's land between modeling
> with OO and modeling with XML Schema. It's not exactly straightforward and
> I have yet to figure out how this mixing will impact our code base.
>
> The GeoAPI model reflects the fact that we're really not willing to commit
> to a single expression of a feature model (OO or XML Schema), and require
> all alternate expressions to undergo translation back and forth into the
> core model. THe model itself has to do everything. "Design by committee".
> OO vs. XML Schema: a knock down drag out fight of the titans. Little guys,
> beware. :)
>
>
Do you think that "schema-assisted" object model mapping is a reasonable
compromise - as long as we have the extension points to extend the
schema with object libraries - such as GML primitives, coverage
primitives, custom operations
can we get both a simpler implementation and more flexibility by this
one mechanism?
>> FeatureType should be reserved for the target schema, which we may build
>> an in-memory data model for, or potentially something that we can at
>> least map queries and outut formatting to.
>>
>> Two FeatureTypes are equal if they have the same namespace and element
>> name. If something has been allowed to declare FeatureTypes that have
>> the same identifier but different content, this is logically a
>> configuration error, and should be thrown at config load time.
>>
>> If a Features of a given FeatureType may be partially resolved to
>> support queries or responses (attribute sets) this should not change the
>> FeatureType.
>>
>
> If the feature reader returns a partially resolved feature, how are the
> resolved attributes distinguished from the unresolved ones?
private flag I guess.
> And how does
> the feature know how to resolve the unresolved attributes? The knowledge
> of the persistence layer remains in the reader, I think...
>
>
Yep - and the feature can retain a private hook to the reader perhaps?
> Might I suggest we augment the above definition to include that a
> FeatureType is just a description of a data structure, but contains no info
> about how values of various attributes are populated? Urgh. I think this
> implies we need an "available" flag.
>
yep - but not necessarily part of the API if its the feature's
responsibility to handle lazy instantiation.
> Hmmm. Once the feature leaves the feature reader, I don't see it ever
> being able to resolve missing attributes on its own. It will have to be
> recombined with a reader at some point.
again, is it too ugly for it to retain private hook to the reader?
> This seems to argue for
> considering unresolved attributes permanently unresolved, which would merit
> a different feature type.
>
>
I think this is not a new feature type, but maybe an error if you dont
ask for everyhting you will need, maybe its OK for the feature instance
to throw an exception if an unresolved attribute is accessed? I'd
rather correct behaviour than start managing vague definitions.
> Urgh.
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
