[EMAIL PROTECTED] wrote on 12/28/2006 02:41:12
PM:
> Well, all this depends on what a FeatureType is, semantically. The
> problem is that we have deviated from the ISO/GML definition to
> something more closely connected with an in-memory representation of a
> physical implementation. In some cases this is a workable surrogate, but
> what is the meaning of "ReType" for example.
>
> I dont beleive we have a coherent definition of FeatureType once we lost
> the real one.
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.
> 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. :)
> 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? And how does
the feature know how to resolve the unresolved attributes? The knowledge
of the persistence layer remains in the reader, I think...
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.
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. This seems to argue for
considering unresolved attributes permanently unresolved, which would merit
a different feature type.
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
