[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] maps
After working for a little while on a project involving maps, it's very clear to me that W3C XML Schema Part 2: Datatypes was not written by cartographers. There's no type in WXS for locations. I can't use the built-in types to express something like: <zoo> <name>Utica Zoo</name> <lat>75°15'00" N</lat> <long>43°05'00" W</long> </zoo> I can create a type with a regular expression constraining its lexical appearance, but there's no value space, so I can't compare, for instance, 75°15'00" N with 75.2500° N. I have similar problems created by the lack of any notion of units in W3C XML Schema. When I was looking at GPS devices, I found information that the accuracy under the forest canopy was off by 7-21. Mentally I read that as feet (since I was in the US), but it was of course in meters. Since the particular maps I'm making are only 52 feet 8 inches in diameter, 23-67 feet off is kind of a problem. I'm also creating software which will hopefully be used in both US and metric environments, so an understanding of units is crucial. (For a kicker, I'm using compass coordinates, which plot differently from polar coordinates. How to explain that?) From one perspective, it seems like the right answer is to bang on the W3C XML Schema Working Group's door and ask for new primitive types which have value spaces capable of dealing with the common lat/long information (which is less complicated than date/time, surely!) and which can cope with units in some form. While I know that the W3C XML Schema Working Group did consider units at some point, it didn't make it, and as a result tools will be a long time coming. While lat/long may be less complex than gHorribleKluge in its parts, it also has some options - degrees/minutes/seconds vs. decimal degrees - which aren't really handled by any of the existing types. A more rational perspective (IMHO) is to work from local understandings of the value space and build my own tools for getting there. Using tools like Regular Fragmentations I can break the lexical notations into smaller pieces (and I'm planning an update to RegFrag to handle the d/m/s vs. decimal d fallback issue.) Once I create those smaller pieces, I can write local logic which handles the particular semantics I need, and I can even share that logic through the magic of open source. Once I've started doing that, it's not very difficult to look back at WXS Part 2 as a misguided effort by programmers and database vendors to give the world the types they use and no others. Dates, times, and numbers are all amenable to processing like the kind I've described above for lat/long, and there's no need to bind everyone to an identical set of vaguely primitive types. The biggest problem I have with strong typing is that most problems need different types and particularly different understandings of value spaces. While programmers may be fooled into thinking that the set of primitive types they use in their code is somehow magically blessed, there's no such blessing once you step outside the world of programmers. A more open approach where local systems include and perhaps share the logic they use to interpret information using a combination of explicit markup and familiar lexical notation seems vastly preferable to the current approach of a fixed set of types which only understand a very few lexical notations. It also seems a better fit with that evil word "extensible", which I always took to be at the heart of what XML had to offer markup. Markup is a pathway to the locally appropriate meaning of the information, not a final arbiter of what is or isn't a proper date. Anyone for GenCode? I didn't think so. Simon St.Laurent "Every day in every way I'm getting better and better." - Emile Coue
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|