gml4j-devel Mailing List for GML4J
GML Schema Interpreter
Status: Inactive
Brought to you by:
amilanovic
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Aleksandar M. <ami...@ga...> - 2002-04-02 19:14:23
|
Hi All, I've just released a new version of GML4J available at http://sourceforge.net/project/showfiles.php?group_id=26483. Check the release notes to see what's new. Cheers, Alex |
From: Aleksandar M. <ami...@ga...> - 2002-03-28 06:42:03
|
Hi All, I've been trying to improve the spaghetti schema parser part of GML4J. It seems like I am on the right track, as first tests have shown promising results. There are also some other changes. The most noticeable will be the change in the package names because people have complained about com.galdosinc. I changed it to something less Galdosian com.gmlcentral, although this domain is also owned by Galdos. Ideally, we'd have the domain org.gml4j, but we're not committed to only one open-source project, so we'd like to avoid having to register a domain for each one of them. Let me know if you strongly dislike this domain name. If nobody complains with good reason, I'll commit the changes. The old package names will not be used. I've made the schema parser completely independent of prefixes. Earlier the XML Schema namespace had to be prefixed with xsd. Now, it can be any prefix, or no prefix at all for the default namespace. The new parser should also treat references and global attributes better. There are still issues with things like enumerations. Not all schema types are correctly supported. If you have problems with GML4J, let me know. I am thinking about overhauling the entire object model, and to introduce things like geometry property, feature property, to provide a more fine-grained distinction between GML constructs. The DOM-dependent classes will go away. Instead, there will be new classes that dependend on no other object model. Object factories will be used for their creation. In addition, I've upgraded GML4J to the latest libraries (xerces 2.0.1, jdom beta 8), and replaced werken.xpath with jaxen beta 8. This should provide better compatability with other newer programs that might use GML4J. I hope to wrap up the schema parser changes this weekend. For other changes, you'll have to be more patient. P.S. I am contemplating publishing the schema parser as a separate API. It could be useful in non-GML XML applications too. later Alex ---------------------------------------------------------------------------- --------- Aleksandar Milanovic | Privileged or confidential information may be contained Software Engineer | in this message. If this message was not intended for you, Galdos Systems Inc. | destroy it and notify us immediately. Tel: (604) 484-2750 | Opinions, conclusions, recommendations, and other Fax: (604) 484-2755 | information presented in this message are not given or ami...@ga... | necessarily endorsed by my employer or firm. |
From: Cameron S. <csh...@bi...> - 2002-02-21 10:00:18
|
Comments inline: On Thursday 21 February 2002 08:48, Aleksandar Milanovic wrote: > Hi All, > > I wouldn't mind participating on the conceptual level, but I will have no > time to do programming myself (unfortunately). I expect your knowledge of GML is better than ours, and some well place advice from you at the design stage could save us lots of work downstream. > > A few comments: > 1. The freefs project, VFNY's open-source WFS hosted on SourceForge, > already covers parts of the goals here. It is a WFS and has a SAX GML > parser, although I have no clue if the parser is exactly what you had in > mind. Also, check the license, it may be different from yours. Yes, you are right on track. The freefs project has been renamed GeoServer, and Rob H has already been joining us for discussions. > 2. Some IRC time slots are inconvenient for me. For example, 8am in NYC is > 5am in Vancouver. The timeslot we are looking at is 10am in Vancouver. Is that OK by you? See, the following meeting planner URL: http://www.timeanddate.com/worldclock/meetingtime.html?day=27&month=2&year=2002&p1=136&p2=240&p3=262&p4=179&p5=256 > 3. Although I am an author of GML4J, I am not convinced that it should be > extended as is. The current implementation is somewhat inefficient in that > it depends on the DOM tree (or rather sits on top of it). It'd be better to > have GML objects that are independent of other object models, but can be > generated, perhaps, from other object models such as DOM. In this sense, > GML SAX parser would be useful. OK, it would be good to have your ideas on this. |
From: Aleksandar M. <ami...@ga...> - 2002-02-20 21:44:54
|
Hi All, I wouldn't mind participating on the conceptual level, but I will have no time to do programming myself (unfortunately). A few comments: 1. The freefs project, VFNY's open-source WFS hosted on SourceForge, already covers parts of the goals here. It is a WFS and has a SAX GML parser, although I have no clue if the parser is exactly what you had in mind. Also, check the license, it may be different from yours. 2. Some IRC time slots are inconvenient for me. For example, 8am in NYC is 5am in Vancouver. 3. Although I am an author of GML4J, I am not convinced that it should be extended as is. The current implementation is somewhat inefficient in that it depends on the DOM tree (or rather sits on top of it). It'd be better to have GML objects that are independent of other object models, but can be generated, perhaps, from other object models such as DOM. In this sense, GML SAX parser would be useful. Alex > -----Original Message----- > From: gml...@li... > [mailto:gml...@li...]On Behalf Of Cameron > Shorter > Sent: Wednesday, February 20, 2002 3:12 AM > To: Geotools Discussion; Mapbuilder Develop; > gml...@li...; Martin Davis; op...@bb...; > wf...@op... > Subject: [Gml4j-devel] IRC discussion for opensource GML development > > > Hello, > > Intro > ==== > Two open source projects have been putting heads together > recently to develop > common libraries to handle Geographic Markup Language (GML) and related > issues: > > http://geotools.sourceforge.net (GIS applet for viewing maps) > http://geoserver.sourceforge.net (Web Feature Server / Simple > Feature Server). > > Issues we need to resolve are: > ======================== > 1. How to extent the Java Topology Suite > http://www.vividsolutions.com/jts/main.htm to include attributes (it > currently provides a suite of GIS functions). > 2. Writing a SAX GML parser. > 3. Extentions to http://gml4j.sourceforge.net > 4. It would be great if we could tap into a GML expert. > 5. We are working toward a Web Feature Server (WFS) client and server. > > IRC Session > ========== > We are currently holding weekly IRC meetings. The next one is tentively > planned for: > Tuesday Feburary 26, 2002, at 1800 GMT. > (See the following URL to find a timeslot near you). > http://www.timeanddate.com/worldclock/meetingtime.html?day=27&mont h=2&year=2002&p1=136&p2=240&p3=262&p4=179 If you are interested in participating, then let me know: 1. What timezone you are in, 2. What times suite you, 3. What bits interest you. Email List ======== Discussion of issues is currently happening on the geotools developers list. http://sourceforge.net/mail/?group_id=4091 . If there is enough external interest, we may need to move this elsewhere. Hope to hear from you soon, Cameron (geotools developer). _______________________________________________ Gml4j-devel mailing list Gml...@li... https://lists.sourceforge.net/lists/listinfo/gml4j-devel |
From: Cameron S. <csh...@bi...> - 2002-02-20 11:10:39
|
Hello, Intro ==== Two open source projects have been putting heads together recently to develop common libraries to handle Geographic Markup Language (GML) and related issues: http://geotools.sourceforge.net (GIS applet for viewing maps) http://geoserver.sourceforge.net (Web Feature Server / Simple Feature Server). Issues we need to resolve are: ======================== 1. How to extent the Java Topology Suite http://www.vividsolutions.com/jts/main.htm to include attributes (it currently provides a suite of GIS functions). 2. Writing a SAX GML parser. 3. Extentions to http://gml4j.sourceforge.net 4. It would be great if we could tap into a GML expert. 5. We are working toward a Web Feature Server (WFS) client and server. IRC Session ========== We are currently holding weekly IRC meetings. The next one is tentively planned for: Tuesday Feburary 26, 2002, at 1800 GMT. (See the following URL to find a timeslot near you). http://www.timeanddate.com/worldclock/meetingtime.html?day=27&month=2&year=2002&p1=136&p2=240&p3=262&p4=179 If you are interested in participating, then let me know: 1. What timezone you are in, 2. What times suite you, 3. What bits interest you. Email List ======== Discussion of issues is currently happening on the geotools developers list. http://sourceforge.net/mail/?group_id=4091 . If there is enough external interest, we may need to move this elsewhere. Hope to hear from you soon, Cameron (geotools developer). |
From: Aleksandar M. <ami...@ga...> - 2001-12-02 19:55:59
|
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 > > |
From: Rob H. <rob...@vf...> - 2001-11-29 22:17:52
|
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... |
From: Rob H. <rob...@vf...> - 2001-11-20 23:03:47
|
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 |
From: Cameron S. <ca...@so...> - 2001-11-19 20:42:10
|
Great to see this interest Rob. FYI: James Macgill (key geotools developer) has got an alpha version of GML rendering into geotools using gml4j. Last time I was talking with him he was still having problems with polygons. So this might be a starting point for you. If you checkout the geotools code from http://geotools.sf.net , have a look at: geotools/src/uk/ac/leeds/ccg/gml/GMLReader.java He also has a demo at: http://www.ccg.leeds.ac.uk/geotools/demos/gml/ Rob Hranac wrote: > > Alex et. al., > > I might be interested in leading this. I care about encouraging client WFS > development and it is probably a good idea for me to see the other side of > the fence as well (GML parsing as opposed to be GML generation). Let me > take a deeper look at the code this week and see what I think. Off-hand, I > think that I might have a fairly simple approach that will work well with > your existing code. > > Regards, > Rob > > > -----Original Message----- > > From: gml...@li... > > [mailto:gml...@li...]On Behalf Of > > Aleksandar > > Milanovic > > Sent: Thursday, November 15, 2001 6:37 PM > > To: GML4J-USER; GML4J-DEV > > Subject: [Gml4j-devel] saxGML4J > > > > > > Hi All, > > > > It's been a while since I posted my GML4J manifesto, but I've > > been too busy > > to do any followup work. Since this is unlikely to change > > soon, I am now > > looking for somebody to coordinate work on saxGML4J, which is > > deemed as the > > first priority. I can provide technical supervision and > > answer questions, > > but that's about it. > > > > The saxGML4J coordinator must be able to come up with a draft > > solution for > > the saxGML4J based on the current GML4J code (or parts of > > it). It should > > address any existing problems in GML4J (e.g. support for > > latest XML schema > > version, critical bugs). The coordinator may be the main (or > > even only) > > developer on saxGML4J, that's cool with me. > > > > Eagerly awaiting volunteers, > > Alex > > ------------------------------------------- > > > > Tesla: ?Science is but a perversion of itself unless it has > > as its ultimate > > 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. > > > > > > > > _______________________________________________ > Gml4j-user mailing list > Gml...@li... > https://lists.sourceforge.net/lists/listinfo/gml4j-user -- Cameron Shorter Web Mapping Manager Social Change Online 248 Johnson St Tel: +61 (0) 2 9692 5115 Annandale NSW 2038 Fax: +61 (0) 2 9692 5192 Sydney, Australia http://webmap.socialchange.net.au |
From: Rob H. <rob...@vf...> - 2001-11-19 15:58:39
|
Alex et. al., I might be interested in leading this. I care about encouraging client WFS development and it is probably a good idea for me to see the other side of the fence as well (GML parsing as opposed to be GML generation). Let me take a deeper look at the code this week and see what I think. Off-hand, I think that I might have a fairly simple approach that will work well with your existing code. Regards, Rob > -----Original Message----- > From: gml...@li... > [mailto:gml...@li...]On Behalf Of > Aleksandar > Milanovic > Sent: Thursday, November 15, 2001 6:37 PM > To: GML4J-USER; GML4J-DEV > Subject: [Gml4j-devel] saxGML4J > > > Hi All, > > It's been a while since I posted my GML4J manifesto, but I've > been too busy > to do any followup work. Since this is unlikely to change > soon, I am now > looking for somebody to coordinate work on saxGML4J, which is > deemed as the > first priority. I can provide technical supervision and > answer questions, > but that's about it. > > The saxGML4J coordinator must be able to come up with a draft > solution for > the saxGML4J based on the current GML4J code (or parts of > it). It should > address any existing problems in GML4J (e.g. support for > latest XML schema > version, critical bugs). The coordinator may be the main (or > even only) > developer on saxGML4J, that's cool with me. > > Eagerly awaiting volunteers, > Alex > ------------------------------------------- > > Tesla: Science is but a perversion of itself unless it has > as its ultimate > 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. > > > |
From: Ian T. <ia...@ge...> - 2001-11-16 12:20:41
|
At 15:36 15/11/01 -0800, Aleksandar Milanovic wrote: >Content-Type: text/plain; > charset="iso-8859-1" >X-MIME-Autoconverted: from 8bit to quoted-printable by >cervantes.galdosinc.com id PAA02765 > >Hi All, > >It's been a while since I posted my GML4J manifesto, but I've been too busy >to do any followup work. Since this is unlikely to change soon, I am now >looking for somebody to coordinate work on saxGML4J, which is deemed as the >first priority. I can provide technical supervision and answer questions, >but that's about it. >The coordinator may be the main (or even only) >developer on saxGML4J, that's cool with me. I'm afraid I can't provide enough time to be coordinator but I am interested in contributing to the development process. Ian |
From: Aleksandar M. <ami...@ga...> - 2001-11-15 23:35:45
|
Hi All, It's been a while since I posted my GML4J manifesto, but I've been too bu= sy to do any followup work. Since this is unlikely to change soon, I am now looking for somebody to coordinate work on saxGML4J, which is deemed as t= he first priority. I can provide technical supervision and answer questions, but that's about it. The saxGML4J coordinator must be able to come up with a draft solution fo= r the saxGML4J based on the current GML4J code (or parts of it). It should address any existing problems in GML4J (e.g. support for latest XML schem= a version, critical bugs). The coordinator may be the main (or even only) developer on saxGML4J, that's cool with me. Eagerly awaiting volunteers, 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. |
From: Aleksandar M. <ami...@ga...> - 2001-10-25 03:05:52
|
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. > > > > > > > > > > > > |