[Gml4j-devel] RE: GML4J manifesto

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

Good questions.

One of the weaknesses of the current GML4J is the fact that part of the
logic for recognizing features, geometries and other GML4J constructs is
placed in the DOM-based part of the code. With saxGML4J, we can move this
logic into an independent unit that will be usable by any party.
Note that current SAX parsers are used similarly. Current DOM
implementations use them to parse XML files and get notified of elements,
attributes, etc.

saxGML4J will be a specialization of the SAX parsers, which receives SAX
events and converts them to GML events (e.g. feature, geometry, ...). From
this perspective, the existence of saxGML4J would simplify the development
of mGML4J. Let me know if you're interested in contributing to saxGML4J.
There are other interested people, too.

Therefore, having saxGML4J would facilitate the creation of different GML
data structures (DOM, kDOM, myOwnDOM, ...). You mentioned having a common
interface for all these data structures. This interface already exists, it
is the abstract part (mostly interfaces) of GML4J. It may not be perfect,
but it's a start. Suggestions for its improvement are welcome. Obviously,
data modification and marshalling would be nice to have.

jbGML4J based on Castor successfully addresses issues such as data
modification, validation and marshalling, but it was not designed for a
mobile platform. We should look into how we can put all these under the same
umbrella. The aforementioned abstract interface seems to be the way to go.
Are there any volunteers willing to overhaul the abstract GML4J interface?

As you can see, there is a lot work, but little time :). I suggest the
following work organization:

1. Work on saxGML4J and the abstract interface may proceed in parallel.
Preliminary work for jbGML4J can also be done in parallel with the previous
two.
2. Bringing jbGML4J and the current domGML4J to conform to the abstract
interface, and implementing mGML4J should start only after step 1 has been
completed.


Let me know what you think and whether you're interested in participating.

thx
Alex



--
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: Scott Lewis [mailto:le...@ma...]
> Sent: October 23, 2001 11:50 PM
> To: Aleksandar Milanovic
> Subject: Re: GML4J manifesto
>
>
> Alek,
>   Thank you for the update. I was going to update you yesterday,
> but since you released the manifesto today it was just as well
> that I did not.
>   The research I am doing into kDOM would seem to lend itself
> well to the third action item in your manifesto. However, I have
> two questions/thoughts:
>    1) If one were to incorporate an alternate DOM model in the
> current code, then it would seem to mean the redesign of classes
> that use org.w3c and jdom code. The former is the set of packages
> for the de facto dom model and which inituitively seem too
> resource intentive for small, location-based devices. As for
> jdom, it seems that using the org.w3c classes is irrevocably tied
> into its core code. It seems that one has two options: one could
> create a parallel branch of gml4j classes from scatch for each
> alternate DOM model or one could create a set of interfaces that
> could act as a proxy to disparate DOM models and have a one core
> set of gml objects use the aforementioned interfaces. My first
> preference is the latter for it obviously stresses code-reuse
> (one of the tenants of OO programming of course). Perhaps my
> thinking is completely skewed. If so, then forgive me for I am a
> neophyte to this api and have not had the time I wish to really
> know it depth and breath in full (but !
> will).
>    2) Noticing the intentions of including a SAX parsing model in
> the gml4j api, per action item 1 in your manifesto, would the
> latter question of mine be useless in the asking? Mainly, if a
> smaller device could use a SAX parser would one even wish to
> support a DOM model conducive to a smaller device? And if so,
> given a limited amount of developer resources, which one would
> take priority in implementation?
>    I hope these do not seem like stupid questions, Alek. As
> always, I appreciate all the time and effort you have give to
> this project and I look forward to working with you in any way I
> can offer.
>
> Regards,
> Scott Lewis
>
> ---------- Original Message ----------------------------------
> From: "Aleksandar Milanovic" <ami...@ga...>
> Date: Tue, 23 Oct 2001 10:54:58 -0700
>
> >Hi All,
> >
> >This email outlines the plans for immediate GML4J development.
> Please notify
> >me if you're interested in contributing to it.
> >
> >The development will proceed on three parallel trails:
> >
> >1. saxGML4J - SAX GML4J
> >2. jbGML4J - JavaBean GML4J
> >3. mGML4J - Mobile GML4J
> >
> >Here's a short description of each:
> >
> >1. saxGML4J
> >SAX parsers parse any XML document, but the information they
> provide is also
> >generic: elements, attributes and similar. It'd be nice to have
> a SAX-based
> >GML4J parser that parser GML data and notifies registered listeners of
> >features, geometries and similar. This solution would be more
> >memory-gracious than the current DOM-based implementation, and
> could be used
> >to create arbitrary data structures.
> >
> >2. jbGML4J
> >jb stands for JavaBean. This implies that the GML Java objects
> that the API
> >will create will be JavaBeans. We will use Castor (http://www.exolab.org)
> >for this. Castor is already capable of creating JavaBeans based on a GML
> >schema, but it cannot easily unmarshal GML documents to Java because GML
> >heavily relies on XSD substitution groups and these are not
> fully supported
> >by Castor. Some possible solutions are:
> >2.1 Enhance Castor to fully support unmarshalling of substitution groups
> >2.2 Create your own unmarshaller for each GML application
> schema. This can
> >be done in at least two ways:
> >2.2.1 Manually code the unmarshaller to support various mappings
> between GML
> >types and corresponding Java objects
> >2.2.2 Automate the process so that the unmarshaller is generated
> from a GML
> >application schema
> >2.3 Dynamically unmarshal a GML document using its schema. This however
> >requires that the schema be present at unmarshalling time, and
> it is similar
> >to 2.2.2.
> >
> >3. mGML4J
> >m stands for mobile. The intention is to explore the
> applications of GML4J
> >in a mobile environment, where memory and processing power are
> scarce. There
> >are "lightweight" parsers which could be used in such environments (e.g.
> >minML2, nanoML). We will try to build a GML parser based on one of this
> >lightweight XML parsers most likely on the Java 2 ME platform.
> >
> >
> >P.S. Before this development begins, we will need to update the GML4J to
> >work with the latest XML schema version.
> >
> >Cheers,
> >Alex
> >
> >
> >
> >
> >--
> >
> >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.
> >
> >
> >
> >
> >
>
>