OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   maps

[ Lists Home | Date Index | Thread Index ]

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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS