RE: [Gml4j-devel] saxGML4j progress

[Aleksandar M. <ami...@ga...>]

Hi Rob,

Sorry for not replying, but it's been quite hectic here lately. The OGC
conference is starting tomorrow, so I won't be able to respond to your
initiative for a little while.

Please be patient :)

thx
Alex

-------------------------------------------
Tesla: =93Science is but a perversion of itself unless it has as its ulti=
mate
goal the betterment of humanity"
Privileged or confidential information may be contained in this message. =
If
this message was not intended for you, destroy it and notify us
immediately.Opinions, conclusions, recommendations, and other information
presented in this message are not given or necessarily endorsed by my
employer or firm.


> -----Original Message-----
> From: gml...@li...
> [mailto:gml...@li...]On Behalf Of Rob Hranac
> Sent: November 29, 2001 2:20 PM
> To: Gml...@li...
> Subject: [Gml4j-devel] saxGML4j progress
>
>
> 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 parsi=
ng
> 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=3D38173
>
> 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.infose=
t'
> package to include all geometric and feature types.  It would seem to m=
ake
> 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 h=
ow
> this would mesh with the Castor-generated types, but given my experienc=
e
> 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' ty=
pes
> 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 wo=
uld
> 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 t=
o
> assemble GML entities into their appropriate types
> (GMLGeometryFilter).  The
> GMLDocument filter is very low level, but gives potential GML aficionad=
os
> 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 Inse=
rt
> statements, which is useful for my little server.  For demo
> purposes, I have
> used them to do that quintessential XML example: print themselves to th=
e
> 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 t=
he
> 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 O=
GC
> 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...
>
>
> _______________________________________________
> Gml4j-devel mailing list
> Gml...@li...
> https://lists.sourceforge.net/lists/listinfo/gml4j-devel
>
>