Wednesday, May 03, 2006

WWML spec

A few interesting tidbits from the WWML (NASA World Wind Markup Language) 0.93 spec. It adds a few concepts on to GML. It mixes in GML, with the gml namespace, where appropriate and keeps it's own stuff (metadata, display, and dynamic properties) in a wwml namespace. Beyond that, I see no advantages over using KML...

"WWML is a NASA open specification standard that is aimed at becoming the de facto HTML/XHTML extension standard for streaming geospatial data over the internet."

Looking at it as an HTML extension seems to imply that it is intended to focus on the display of map data in web pages. It also implies something quite different from KML, but they compare it to shapefiles... KML is notably absent from the spec, while shapefile is referred to 11 times, and it obviously borrows heavily from KML (as KML -borrows- from GML) It would seem that they wanted to avoid discussing the whole issue of divergent standards, although there are quite a few references to this being a superset of GML, much like KML is.



"Therefore, very rich XHTML documents can be designed for future web-browsers that enable WorldWind type rendering and interaction capabilities."

An interesting idea...but this seems to be irrelevant at the moment- when will these browsers exist?. Defining XML "fragments" that can be embedded in other XML formats really seems to be the only outcome of this notion. I think when when we start to see broader SVG support, that will be way some of these ideas end up getting implemented. I don't see internet explorer building in wwml support any time soon.

"WWML will support binary compressed XML files BXML proposed by CubeWerx and currently implemented in and open-source C-language library for parsing and generating XML and BXML formats under the GNU LGPL license."
I think the ZIP approach (KMZ, gzipped html) is a lot more common than BXML, but they claim that doesn't offer enough compression.

The meat of the spec is the concept where you define display rules for something like wwml:City using a mixture of gml:Feature style with some extra wwml elements , and then use a tag to wrap gml geographic features and their attributes. It seems a little clumsy.

From a parsing convenience standpoint, I don't like to see new elements introduced as attributes of other elements. It usually means you have to parse most of the document to understand it, instead of being able to pull out the bits you want quickly with expressions. For example, I'd have to read all of the feature style definitions to even know I was supposed to be looking for a tag. I think this is one of the things that makes it really easy to write code for KML, the set of tags to expect is small and predefined.

And here, wwml:City is just a display style- not a semantic concept of a "City" with population attributes, etc., those attributes are merely referenced as XPath expressions in the display rules and then become more suprise tags in the placemark definition. You just wrap all of the city placemarks (which are gml:point or the like) in the wwml:City tag (with wwml:name and wwml:population tags inside) to have the display rules applied. If I were writing this I might not use city as my example, it's really more like a styleurl in KML.

Overall, it's a pretty interesting spec. It's a little messy to look at and the domain/range stuff is just plain ugly, but no one was ever meant to read XML- right?


2 comments:

Anonymous said...

SVG support is growing, see http://svg.startpagina.nl

Matt McKnight said...

Yeah, it's taken about 5 years from the time someone first told me we should do online GIS in SVG until it's become more of a practical possibility. I can't see WWML getting going too much more quickly.