On Sat, Feb 14, 2015 at 1:27 AM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
> I've been working a bit more on this, trying to get the Document type
> working with Postgres XML data. I now have code that can extract a Document
> from a postgres XML field.
> Based on what I have done so far, I do have a couple of questions
> concerning the optimal implementation within the context of geotools.
>
> Postgres supports XML Documents and XML fragments. My code currently
> supports both, but this requires parsing into a DocumentFragment rather
> than a Document.
> Many other databases (Oracle, DB2, etc.) only appear to support XML
> Documents (not fragments).
> Based on the conversation above, would it be better only support XML
> Documents (Perhaps requiring a valid schema)?
>
Is there any logical difference, from the user point of view, between
fragment and full document?
The valid schema is probably not a requirement from the p.o.v. of GeoTools
(at least, I can imagine some generic
xml handling code that could live without it), I'm not sure what is going
to happen in WFS land though, there you might
need a schema and a way to either grab it as a resource, or refer to it as
an stable online reference.
>
>
> Since a binding is not defined for the Document, DescribeFeatureType
> quietly throws a NPE when given a Document type, and GetFeatureType still
> displays the content as a string.
>
>
> For full XML Support, it seems the following will be required
>
> 1. Modify SQLDialect Type Mapping to support the XML type, and map to
> Document
> 2. SQL XML to Document Converter for each database:
>
> - Java Default: java.sql.SQLXML
> - PostGIS: org.postgresql.util.PGobject
> - Oracle: oracle.xdb.XMLType
> - DB2: com.ibm.db2.jcc.DB2Xml
> - ...
>
> Works for me... pity that we don't have H2 in the above list, it's the
only JDBC test that is always run, in all builds,
breakage in the other databases happens without anyone getting notified.
> 3. GML Type Mapping and Parser for Document
>
> - Add mapping to buildTypeMappingProfile() in org.geotools.xs.XS.java?
>
>
This is the root of all XML mappings. What would you map it to in terms of
xml type? xs:any as Jody suggested?
I'm wondering if this type of mapping could cause issues with app-schema,
xs:any is kind of
generic, used in several places nowadays, for example, in a few OGC
protocols it's used to allow protocol
extensibility, like for example all WCS 2.0 extension are stuck into a
wcs:Extensions element that contains
xs:any.
Maybe nothing bad will happen, but it's an area that deserves some
attention imho.
Ben, do you have a feel of possible difficulties?
>
> I do not have access to any databases other than PostGIS and Oracle. The
> list of databases that we support and which support XML data types is:
>
> - PostGIS
> - Oracle
> - DB2SQL
> - SpatialLite
> - SQLServer
> - Teradata
>
> Would it be better to write converter code and test cases for all the
> databases, but only test Oracle and PostGIS (Such that we ostensibly
> support the XML type for all of these databases) or only write the
> converter code for Oracle and PostGIS(Such that all code written is
> actually tested)
>
> I'd write a generic test class for all database (JDBCXMLMappingTest or
something like that). About the converter code, I'm not sure,
what is the ResultSet going to give you back? If there is some guidance and
it's uniform, generic converter code (maybe with a chance
to override, one or two databases always like to play the oddball), if not,
per db converter code.
> Andrea - You raised a concern about inserting XML data into other output
> formats, such as shapefiles, etc. For now, would it be be acceptable to
> only support insertion of XML into formats that already have native support
> for this type, and insert plain text in all other cases?
>
I guess I don't mind showing the raw XML, but the toString() of a Document
is going to give you back a "org.w3c.Document@12347" type of string, which
is
not exactly useful, isn't it?
Maybe you could have a smart Document subclass that serializes back to XML
when you call toString()?
Or even just one that returns the empty string, I guess it's still better
than getting a class name and a hashcode user wise (althought
it will make usage of those object in debugging "fun" to say the least).
My other concern is about GML and the schema support for the clients.
Like, if you don't link any schema for your XML documents, you have to use
xs:any and who knows what is going
to happen with the clients (are they going to break?).
But if you have the schema and link it, and maybe use it also in your
DescribeFeatureType, then you're formally
advertising a complex feature, and then you must be able to filter on the
nested attributes (there is no way to
tell you cannot do that)... annoying situation...
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
