Since you are really looking for a formally specified solution (not
necessarily a new element), why not use the META element, which was
designed precisely for this type of document meta-information, and propose
an RFC elaborating a schema for including locational information in
attribute values?
>This markup should go in the HEAD not the BODY, because it is designed
>for machine, not human, processing. It should be an element not an
>attribute, because it should be repeatable (consider a bookstore with
>three branches). The country should be an attribute, because the range
>of values is fixed and finite, and should be required, for obvious
>reasons (although Americans will break this rule).
I don't follow how a single document could contain more than one location
using a single reference in the document HEAD without resorting to multiple
NAMEs or IDs, which would seem to obviate the need for it being anything
more than a set of attribute values. If you are trying to locate the
specific document (most likely by location of author origin, not
necessarily server location), then why the need for repeatability? Are you
trying to markup a specific phrase? How would one implement repeated values
within the same document? How would it be linked to specific text if
located in the HEAD?
As you propose, a solution would be a matter of specifying a standard set
of location codes (similar to the current discussions on LANG language and
ISO country codes) to be used as attributes on allowed elements. Linking to
multiple META elements via ID would be a method of specifying multiple
locations within one document, sort of like the early HTML+ spec for BASE.
If you are trying to specify the location of a specific passage of text
(ie., the name of a bookstore branch), then you could link via attribute to
a named META element in the header, such as:
<META HTTP-EQUIV="location" id="z23" name="US.WV.Wheeling"
content="LatiLong: 40.03 N 80.43 W">
.
.
<A HREF="www.borders.com" LOCATION="z23">Borders Books</A>
although I believe I may be using HTTP-EQUIV here incorrectly. This was not
meant as any sort of alternative, only a quick illustration.
>DEVIL'S ADVOCACY:
[...]
>2. Latitude/Longtitude would be more precise than postal code (but would
> not obviate the need for country), but be a little harder to
> process and a lot less likely for the average user to enter; also,
> perhaps, less useful, since postal codes tend to reflect
> convenience as well as distance.
I must disagree here. Latitude and longitude are certainly more precise,
universal, and not subject to change (as are most postal codes). From
experience I doubt anything would be simpler to process than
latitude/longitude. Having worked with MapInfo and other mapping
applications, I would much prefer a data set that mapped to Lati/Long than
postal codes, especially as regards accuracy. The US Postal Service changes
zip code maps relatively frequently in heavily populated areas; changes are
recorded each year. Anyone with access to a map or atlas can get the
latitude and longitude for any location directly. GPS systems use
latitude/longitude. Values are easily obtained: note the simple "Map" desk
accessory on the Macintosh. This is not to say that postal codes are not
useful, just not as useful _in accurately locating a physical position_,
especially as regards proximity. There is no simple measure of distance
given postal codes. Postal code boundaries are often arbitrary, while
latitude and longitude would allow actual distance calculation using simple
formulae.
Since (in my understanding) the actual attribute values for NAME and
HTTP-EQUIV are only suggested and not limited to or specified within the
DTD, I would recommend drafting an RFC to propose a standard set of
attribute values (or a schema) to be used for site location information. If
the intent is country-specific, postal codes would suffice; if
international, this should obviously include allowances for ex-country
processing (eg., it may be very difficult to get current postal codes for
foreign countries), lending favor to using lati/long, UDM or any other
standard, scientific, non-proprietary formats. This as an addition to
current proposals for language and country would be a very valuable
addition to the community.
Murray
-------------------
HTML 2.0 DTD draft:
[1]: http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_5.html#SEC30
HTML 3.0 DTD draft:
[2]: http://www.w3.org/hypertext/WWW/MarkUp/html3/dochead.html
__________________________________________________________________
Murray M. Altheim, Information Systems Analyst
National Technology Transfer Center, Wheeling, West Virginia
email: murray.altheim@nttc.edu
www: http://ogopogo.nttc.edu/people/maltheim/maltheim.html