Re: [xml-dev] maps

["J. David Eisenberg" <catcode@catcode.com>]

On Sun, 4 Aug 2002, Simon St.Laurent wrote:

> 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.

Or, in another rational perspective, use Relax NG, which lets you 
implement your own data type libraries, which can be shared through the 
magic of open source.

-- 
J. David Eisenberg  http://catcode.com/