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