[Gml4j-devel] saxGML4j progress

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

GMLers,

As previously threatened, I have hacked together a very simple SAX GML
parser.  First, all the things that it ignores/doesn't do:
	namespaces (other than GML)
	validation (other than very basic geometric primitives)
	'multi' geometric types
	abstract geometric types
	user-generated schemas and custom GML types

So, what does it do?  Essentially, it takes the grunt-work out of parsing
geometric types by converting them into Java objects that you can then do
with what you will.  In my tradition of releasing well before I really
should, it is a very primitive alpha that will be buggy, etc. so caveat
emptor.  The things most worth looking at right now are the JavaDocs to see
what you think of the approach.  For lack of a better spot to put it, I have
released it as a package of FreeFS:
	http://sourceforge.net/project/showfiles.php?group_id=38173

Here is what I said that I would do in my last email, versus what I actually
did:
(1)
I SAID ->
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.
I DID ->
Exactly this.  I generated the non-DOM dependent geometric types from
Castor, then hacked out all of the Castor-specific stuff (essentially
marshalling, unmarshalling, and validation).  I also made them non-abstract
and changed their names slightly (appending 'Type' to each primitive).  I
think that an ideal version of GML4j would use all of these as the base
types and then make DOM and Castor-specific extensions of them.  It would be
no problem to change them back to abstract types and unappend 'Type' to them
to make them Castor-compatible.  I would then change my kludgy 'SAX' types
into extensions of these base types.

(2)
I SAID ->
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.
I DID ->
Almost exactly this.  I decided to break this up into two filters, the first
to just pass GML events untouched (GMLDocumentFilter), and the second to
assemble GML entities into their appropriate types (GMLGeometryFilter).  The
GMLDocument filter is very low level, but gives potential GML aficionados
much control over the parsing process with some GML support.  The
GMLGeometry filter is much higher level, because it takes all the GML
parsing away from the developer and returns nicely abstracted Java objects.
You can then extend/use these types to do useful things.  For example, I
have personally extended them to turn themselves into Postgres SQL Insert
statements, which is useful for my little server.  For demo purposes, I have
used them to do that quintessential XML example: print themselves to the
standard output.  The SAX advantages of this are - of course - that you can
get the geometries and associated data one at a time, without having to
worry about reading in the whole document in first.

(3)
I SAID ->
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.
I DID ->
Nothing, yet.  This seems like the logical place to put most of the
namespace support, validation, etc.  Frankly, I am not knowledgeable enough
about SAX to do this quickly and don't have the time right now to learn.
Might do this in a month or two.

That's it.  These features are personally very useful to me, but this
approach is by no means the only one and I am very interested to hear
feedback from other developers and potential users.  I will be at the OGC
Vancouver conference through Wednesday and would be happy to chat it up with
whomever has opinions - look for a goateed New Yorker...

Regards,
Rob Hranac
Director / Senior Developer
Vision for New York
377 Broadway
11th Floor
New York, NY  10013

tel: (212) 219-6052
email: rob...@vf...