LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: I propose (seriously, sorry) another tag
From: [log in to unmask] (Murray Altheim)
Reply-To:[log in to unmask]
Date:Mon, 31 Jul 95 16:14:16 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (118 lines)



Tim Bray ([log in to unmask]) wrote:
>SUMMARY:
>
>Add a Header element that specifies geographical location,
>by nation and postal code.
>
>MOTIVATION:
>
>Many (but not all) of the pages on the WWW describe a resource; in many
>(but not all) of these cases, the geographical location of the resource
>is of interest to its potential users.  Examples are: (a) a user looking
>for a retail outlet (whether it be for cars, haircuts, or rail tickets),
>(b) a user looking for a server to download a large electronic document
>without intervening trans-ocean hops.
[...]
>Obviously, people can (and do) include information about their location
>in the text of their pages.  However, it would be desirable if this
>were included in a formally specified way such that browsers,
>servers, and indexing tools could cooperate to make automatic use of it.

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: [log in to unmask]
      www:   http://ogopogo.nttc.edu/people/maltheim/maltheim.html





Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager