[Gml4j-devel] saxGML4j - going once, twice, ...

[Rob H. <rob...@vf...>]

GMLers,

I think that I will take this on myself - at least as a private project -
since I have decided that I have some need for it in my WFS Transaction
interface.  If people are interested in using my results, I would be happy
to donate them to GML4j.  If others are doing the same thing, please let me
know and I will either use your code or coordinate development, depending on
where you are with your project.  I have poked around a bit - even at
geotools (thanks Cameron) - and I don't see this happening yet.

It would seem to me that the best approach in saxGML4j development would be
to do the following things:
(1) Develop a set of generic (i.e. non-DOM-dependent) GML objects
This would essentially be an expansion of the 'com.galdosinc.com.infoset'
package to include all geometric and feature types.  It would seem to make
conceptual sense to divide them into two separate packages, say
'com.galdosinc.com.infoset.feature' and 'com.galdosinc.com.infoset.geometry'
.  It is not entirely clear to me how this would mesh with the
Castor-generated types, but given my experience with JAXB, they would
probably be very similar.  The DOM stuff should probably eventually be
rewritten to implement extensions of these types, but this is not necessary.

(2) Develop a Geographic element filter
This would essentially pass through untouched all events that do not
correspond to geometric types, and encapsulate all geometric types into
objects from (1) and then pass them onto a SAX parent interface that would
constitute the 'low-level' saxGML4j API.  This abstracts away from all of
the geometric specifics of GML handling, while still giving potential users
low-level SAXish control.

(3) Develop a Feature element filter
This would essentially chain to (2) as a parent filter and generate GML
features.  This is quite a bit more complex than (2) but would provide a
'high-level' saxGML4j API to programmers who didn't really care about the
control afforded by (2).  However, it would still give programmers the
ability to react on a feature by feature basis, instead of reading the whole
document, per the DOM implementation.

Any comments are appreciated.  Am neither a GML nor a SAX expert yet, so I
could be missing concepts here.  Alex, let me know how much you would like
to coordinate efforts.

Regards,
Rob Hranac