Gabriel Roldán wrote:
Hi,
making a quick review of the latest changes in the new FM interfaces I've
found Schema.
Glad it is there, since I was using a kind of type registry on
complex-features branch, and it seems to fit perfectly for that need.
So I just wondered how one Schema instance would relate to another(s), like in
xml schema imports. Or if they might relate at all.
There is no hard relationship between schemas, a schema does have a Name
(basically a URI) that you can
use to store it away in a look up service - like JNDI or a Hashtable. I
assume for your task you will want
to do some form of lazy load the same way justin does with bindings
during parsing.
Think on the following situation: you're parsing a "community schema", aka,
arbitrarily complex GML schema.
For a given schema, all includes are going to be kept on the same Schema
instance, but what happens with imports? should the parsed Schema for my
schema1.xsd hold a reference for the Schema instance holding gml*.xsd?
Well you can do anything you want, I would recommend keeping the GML and
XSD schemas seperate to allow
for reuse.
A common situation would be needing to go look for a type of an attribute
which, though its not directly defined in the FeatureType, belongs to the
same "substitution group" than one of the FeatureType's defined attributes...
You are correct, type lookup is out of the scope here (no pun intended),
if possible I would like to replace our
name and namespace constructs with those in javax.naming.
You could answer that no backpointer is needed, since I should be looking for
the "imported" schema by namespace through JNDI or whatever discovery
mechanism, but what if I'm importing gml2 in one schema and gml3 in another?
don't gml2 and gml3 share the same namespace?
Indeed, they do have different versions though. Seriously when working
on parsing, or assembling a group of these
schemas for a specific task you will want to at your application level
be able to find your schemas. One thing you could
do simply withing the bounds of the current model is make a
Namespace<Name,Schema> called "Global" and keep one
of these for each model you are constructing. (aka one for GML2 and one
for GML3).
I understand access to both of these things is needed when translating
from GML2 to GML3.
I might be just ramping, but wanted to chek if I'm missing some key point.
"ramping"? No I think you got it, and I don't think it is the best
solution either - but it does finally explain the trouble
justin was running into using Name - I would look at some other
alternatives before considering a backpointer.
Jody
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
