Subject: [Geopriv] Draft Updates "GEO TAGS for HTML"

From: Andrew Daviel <[email-masked]>
Date: Mon, 6 Aug 2007 00:02:21 -0700 (PDT)

(I am "not yet dead" - as per Monty Python ...)

At IETF64, there was some opinion expressed that my HTML tagging draft 
might be resubmitted with some tweaks. I subsequently made some changes, 
but dropped it - busy at my day job, my webserver died, anti-spam and 
mail problems dropped me off the list.

However, I get sporadic inquiries and it seems there is still some 
interest in the community. So I would like to try again.

draft-daviel-kaegi-html-geo-tag-07
also at http://geotags.com/geo/draft-daviel-kaegi-html-geo-tag-07.html

I have also had some specific interest in reviving my HTTP draft, by a 
gentleman who wants to send location information with Internet Explorer 
mobile. As I recall, this draft was somewhat further from possible 
acceptance by the WG. In view of the interest expressed, I should ask - 
what would it take to make the HTTP proposal more acceptable ?
(The last version I have is at
http://geotags.com/geo/draft-daviel-kaegi-http-geo-header-05.html)
He also refers to a paper from www2004 archived at ACM but otherwise 
apparently offline, and some work on "GPSWeb", an unmaintained plugin for 
Firefox to add a User-Location header to requests - apparently a similar 
concept to my http proposal.

(In my drafts, in particular the HTML syntax intended for manual 
creation, I have strenuously tried to keep it simple. I have recently 
been trying to write a CalDAV server implementation (RFC 4791,2616,2518)
which convinces me even more that some protocol implementations are too 
complex for their own good)

-- 
Andrew Daviel, TRIUMF, Canada
(also Vancouver Webpages)

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Aug 2007 08:28:13 -0400

For the HTML tags: Why not adopt the names and definitions of the XML  
civic tags, rather than creating yet another labeling hierarchy? That  
way, translating, say, a HELD or DHCP result into the HTML tags  
becomes much easier. Example:

civic.hno = 17

For geo, using the space-separated version of http://georss.org seems  
cleaner as it avoids the various separator-white space permutations  
and can easily be parsed with sscanf, which your scheme can't.

As in

geo.position="45.256 -71.92"

Henning

On Aug 6, 2007, at 3:02 AM, Andrew Daviel wrote:

> At IETF64, there was some opinion expressed that my HTML tagging  
> draft might be resubmitted with some tweaks. I subsequently made  
> some changes, but dropped it - busy at my day job, my webserver  
> died, anti-spam and mail problems dropped me off the list.
>
> I have also had some specific interest in reviving my HTTP draft,  
> by a gentleman who wants to send location information with Internet  
> Explorer mobile. As I recall, this draft was somewhat further from  
> possible acceptance by the WG. In view of the interest expressed, I  
> should ask - what would it take to make the HTTP proposal more  
> acceptable ?
> He also refers to a paper from www2004 archived at ACM but  
> otherwise apparently offline, and some work on "GPSWeb", an  
> unmaintained plugin for Firefox to add a User-Location header to  
> requests - apparently a similar concept to my http proposal.
>
> creation, I have strenuously tried to keep it simple. I have  
> recently been trying to write a CalDAV server implementation (RFC  
> 4791,2616,2518)
> which convinces me even more that some protocol implementations are  
> too complex for their own good)
>
> --

---

From: Andrew Daviel <[email-masked]>
Date: Mon, 6 Aug 2007 10:26:00 -0700 (PDT)

On Mon, 6 Aug 2007, Henning Schulzrinne wrote:

> For the HTML tags: Why not adopt the names and definitions of the XML civic 
> tags, rather than creating yet another labeling hierarchy? That way, 
> translating, say, a HELD or DHCP result into the HTML tags becomes much 
> easier. Example:
>
> civic.hno = 17

Basically, because my drafts predate HELD by some considerable time, and 
I have always been looking for simplicity, such as the TLD country names 
that everyone knows. But if I understand correctly, civic.a1 maps to the 
LSB of geo.region. Splitting geo.region into geo.country and geo.xx (as 
in geo.a1, geo.hno) seems not unreasonable. It was really only intended 
as a check against human error in geo.position, anyway (getting the sign 
wrong in longitude, mostly - a common mistake)

>
> For geo, using the space-separated version of http://georss.org seems cleaner 
> as it avoids the various separator-white space permutations and can easily be 
> parsed with sscanf, which your scheme can't.
>
> As in
>

I see no particular problem parsing commas or semicolons; I have some 
code
    sscanf(position, "%lf ; %lf", &DocY, &DocX)
   "White space .. in the format string match any amount of white space,
     including none, in the input"
while semicolon is used e.g. in existing "Content-Type: media;charset"
so I see no advantage in changing to a space.

- Martin Kofahl's proposed update of the HTTP spec is available at
http://geotags.com/geo/draft-daviel-kaegi-http-geo-header-06.txt
I have not finished reviewing it.

(I'm off sailing, so further replies in the next 2 weeks may depend on 
fair weather and cellphone coverage)

regards

Andrew Daviel
TRIUMF/Vancouver Webpages

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Aug 2007 13:30:30 -0400

On Aug 6, 2007, at 1:26 PM, Andrew Daviel wrote:

>> For the HTML tags: Why not adopt the names and definitions of the  
>> XML civic tags, rather than creating yet another labeling  
>> hierarchy? That way, translating, say, a HELD or DHCP result into  
>> the HTML tags becomes much easier. Example:
>>
>> civic.hno = 17
>
> Basically, because my drafts predate HELD by some considerable  
> time, and I have always been looking for simplicity, such as the  
> TLD country names that everyone knows. But if I understand  
> correctly, civic.a1 maps to the LSB of geo.region. Splitting  
> geo.region into geo.country and geo.xx (as in geo.a1, geo.hno)  
> seems not unreasonable. It was really only intended as a check  
> against human error in geo.position, anyway (getting the sign wrong  
> in longitude, mostly - a common mistake)

This has nothing to do with HELD. The labels are defined in RFC 4119  
(and the current pdif-lo draft), which predate your draft. You may  
want to take a look at it.

>
>
>>
>> For geo, using the space-separated version of http://georss.org  
>> seems cleaner as it avoids the various separator-white space  
>> permutations and can easily be parsed with sscanf, which your  
>> scheme can't.
>>
>> As in
>>
> I see no particular problem parsing commas or semicolons; I have  
> some code

The space-only version simply conforms to the XML version. The  
semicolon adds no particular value here.

> (I'm off sailing, so further replies in the next 2 weeks may depend  
> on fair weather and cellphone coverage)
>
> regards
>
> Andrew Daviel

---

From: Martin Kofahl <[email-masked]>
Date: Tue, 7 Aug 2007 16:15:41 +0200

Before discussion goes off course:

HTML-geo-tags vs. HELD and RFC 4676:

Please consider that HTML-geo-tags have a different purpose than HELD 
and RFC 4676. HTML-tags have nothing to do with providing the location 
information for and about clients. HTML-tags will be more or less static 
as any other meta tags in web pages.

The great benefit of Mr. Daviels proposal: it's simple, so that it can 
be used by webmasters who don't care about geographic things but may 
still provide geo-information in this way improving the web.

HTTP-headers:

This has much more to do with HELD & Co. 'cause discovered location 
information will be embedded in http request. In general, it's a good 
idea avoiding conversions. Since headers won't be used manually 
(contrary to html-tags), they might be more comprehensive as you might 
have seen in the new http-geo-draft. I did only consider using Dublin 
Core elements, but they didn't meet the requirements (e.g. heading). 
I'll take a deeper look at georss but it looks as one must add a few 
more elements from GML.

Best regards!
Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Aug 2007 11:48:27 -0400

The reason to use as much of the existing mechanisms as possible is  
precision. We've gone through a fair amount of effort to think about  
the tags, so that the receiver actually knows what they mean, across  
country boundaries. This has nothing to do with HELD, although mobile  
devices may well publish information about themselves that way.  
Precisely because webmasters don't know anything about geo and civic  
data, we shouldn't leave them to their own guesses. I don't see the  
4119 tags as complex, as they correspond pretty naturally to the way  
that people write their address. Well-structured information is  
important since the most important consumer of this information are  
likely to be search engines, not people.

On Aug 7, 2007, at 10:15 AM, Martin Kofahl wrote:

> Please consider that HTML-geo-tags have a different purpose than  
> HELD and RFC 4676. HTML-tags have nothing to do with providing the  
> location information for and about clients. HTML-tags will be more  
> or less static as any other meta tags in web pages.
>
> The great benefit of Mr. Daviels proposal: it's simple, so that it  
> can be used by webmasters who don't care about geographic things  
> but may still provide geo-information in this way improving the web.
>
>
> HTTP-headers:
>
> information will be embedded in http request. In general, it's a  
> good idea avoiding conversions. Since headers won't be used  
> manually (contrary to html-tags), they might be more comprehensive  
> as you might have seen in the new http-geo-draft. I did only  
> consider using Dublin Core elements, but they didn't meet the  
> requirements (e.g. heading). I'll take a deeper look at georss but  
> it looks as one must add a few more elements from GML.
>
>
> Best regards!
> Martin
>
>

---

From: Martin Kofahl <[email-masked]>
Date: Tue, 7 Aug 2007 18:09:27 +0200

Not sure whether your post was about html tags, headers or both.

You'd like to see the location object as described in 4119 used for
'tagging' websites (html use), right? E.g.

    <gp:location-info>
       <cl:civicAddress>
         <cl:country>US</cl:country>
         <cl:A1>New York</cl:A1>
       </cl:civicAddress>
    </gp:location-info>

Shall it be included as comment, directly, translated in some meta-tag
style, other possibilities?

However, you hopefully won't insert it into http headers!? WAP tried to
make use of xml in http headers, I don't think it was a good idea.

Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Aug 2007 13:24:36 -0400

Sorry, I maybe wasn't clear. What I propose is much simpler:

<meta name="civic.country" content="US" />
<meta name="civic.a1" content="NY" />
<meta name="civic.hno" content="1214" />

or

<meta name="geo.point" content="40.3 50.3"/>

I'm not opposed to XML inclusion in HTML, either, but I'm not  
religious about it. The most important aspect is clear labeling so  
that information can easily be transformed across different syntactic  
renderings.

On Aug 7, 2007, at 12:09 PM, Martin Kofahl wrote:

>> The reason to use as much of the existing mechanisms as possible  
>> is precision. We've gone through a fair amount of effort to think  
>> about

---

From: Andrew Daviel <[email-masked]>
Date: Wed, 8 Aug 2007 12:30:56 -0700 (PDT)

On Mon, 6 Aug 2007, Henning Schulzrinne wrote:

> This has nothing to do with HELD. The labels are defined in RFC 4119 (and the 
> current pdif-lo draft), which predate your draft. You may want to take a look 
> at it.

I should have said "my original draft", which predates RFC 4119 by some 5 
years.

> The space-only version simply conforms to the XML version. The semicolon adds 
> no particular value here.

True. It's just a separator that doesn't occur in the data.

The geo.xxx data occur in HTML META elements (or HTTP headers), not XML.
The HTML elements in particular are intended to be lightweight and  to 
not require the mandatory correctness of XML to ease their adoption by 
Web page creators.
While a space would work equally well, I don't see any advantage in 
changing existing software to conform to a standard that does not apply.
Unless, of course, it's the majority opinion that it should be changed to 
progress the draft.

regards, Andrew

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 10:22:23 -0400

I hope we're not having the discussion based on "existing software",  
as this essentially means that you might as well stop asking this  
group for input.

On Aug 8, 2007, at 3:30 PM, Andrew Daviel wrote:

> The HTML elements in particular are intended to be lightweight and   
> to not require the mandatory correctness of XML to ease their  
> adoption by Web page creators.
> Unless, of course, it's the majority opinion that it should be  
> changed to progress the draft.
>

I think GEOPRIV is a pretty good example that the IETF has no good  
way to determine majorities reliably :-)

My general concern is that inconsistency leads to mistakes. This  
working group, at least, should try to stick to one way to encode data.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 10:51:55 -0400

Andrew

In addition to the comments Henning makes, which I agree with, your draft
commits a common error which should not be repeated.

It assumes that a location which is determined by a civic street address can
be converted to geo-coordinates with impunity.  This is wrong, and it is a
very bad idea to start with what we call a civic, and make a geo from it,
unless you understand quite thoroughly what will be done with that geo.

The reverse is also true: if the location was actually measured into geo
coordinates, don't convert it to civic unless you know what happens to it.

Conversion among civic and geo requires a database.  There is no universal
database, and each database has different conventions for how conversion is
done.  Each database has some level of error.  If you convert, and then some
element downstream from your conversion converts back, and doesn't use the
same database as you did, an error is very likely to occur. 

We suggest that when you specify a method for carrying a location, that you
carry geo or civic interchangeably, and that you advise users of your
mechanism that they maintain the original form that the location was
determined.  This means you should not require a geo+country code and some
informal version of civic, but rather that you should accept either a geo or
a civic, and require that the sender send what was measured, and not a
conversion of it.

We have also spent a good deal of time making sure we can represent a civic
anywhere in the world.  We may not have it completely correct, but we have
done a lot of work on that aspect.  You need to have a particularly good
reason to ignore that work, or think the problem is easier.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, August 10, 2007 10:22 AM
> To: Andrew Daviel
> Cc: [email-masked]
> Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML"
>

---

From: "Felix Kaegi" <[email-masked]>
Date: Fri, 10 Aug 2007 21:27:26 +0200

Brian

Please allow me to advocate here:

It is necessary to understand a little how geo enabled search engine
algorithm
can full text and geo index html documents.

The geo.position tag is the most relevant for indexing.

Most of the HTML document authors nowadays can deal very well with GPS data
or generate a coordinate out of an address with all the internet based
address databases
available.

The geo.placename tag is described in the drafts as follows:

   The optional identifier "geo.placename" is used for a free text
   representation of the position, for example "city, province" or
   "town, county, state".

It is an optional tag and is not further structured due to several reasons.

First - the world does not speak English only and location names are often
written
in many different languages. For example in Switzerland we have four
official languages
and there for many names for the same place.

Second - the political structure of an address/location varies all over the
world

Third - location names change often due to political changes

However, the semantics of this tag is simple and easy: 
To be read from left to right like decreasing accuracy in naming the
location.

And all in the end - it is as the draft says: "... used for a free text
   representation of the position ..." Thats what people want!

Conversion between this two tags may happen now on a meta level:

Search engine algorithms may analyze from thousands of HTML documents nearby
a certain position all possible naming variations and therefore generate
meta info
to also leverage full text based geo search on HTML documents that are not
yet
geo tagged but nevertheless already contain address information in their
full text.

The HTML geo tag draft update we are awaiting to be relisted
http://geotags.com/geo/draft-daviel-kaegi-html-geo-tag-07.html 
and Martin Kofahl's proposed update of the HTTP geo header draft
http://geotags.com/geo/draft-daviel-kaegi-http-geo-header-06.txt
we are awaiting Andrew to review when back from vacation
work together hand in hand like the Ying and Yang for geo enabling HTML
searching engines.

Arguing about the syntax of identifiers or separators to me seems like
arguing about the
choice of variable names in a math proof instead about the proof itself.

Since too long the internet community is awaiting for any proposal from the
IETF/W3C - it seems
right now as the Wikipedia community is taking over lead in the de facto
standardization:
http://en.wikipedia.org/wiki/Geotag

Nobody cares about space-only or semicolon separators -
People are using it already - Wikipedia itself too!

felix

-----Ursprüngliche Nachricht-----
Von: Brian Rosen [mailto:[email-masked]] 
Gesendet: Freitag, 10. August 2007 16:52
An: 'Andrew Daviel'
Cc: [email-masked]; 'Henning Schulzrinne'
Betreff: RE: [Geopriv] Draft Updates "GEO TAGS for HTML"

Andrew

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 15:35:25 -0400

I take your message as a "please don't send any further comments,  
we'll ignore them anyway" response. Thanks for clarifying this.

---

From: Martin Kofahl <[email-masked]>
Date: Fri, 10 Aug 2007 22:38:45 +0200

Dear Mr. Schulzrinne,

from my point of view it's an answer to the point of critique that the 
draft assumes a "location which is determined by a civic street address 
can be converted to geo-coordinates". The draft doesn't assume it. No 
conversion is intended.

Mr. Kaegis answer in short ;-)

Kind regards!
Martin Kofahl

Henning Schulzrinne wrote:
> I take your message as a "please don't send any further comments, we'll 
> ignore them anyway" response. Thanks for clarifying this.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 10 Aug 2007 17:01:21 -0400

I did not read the answer that way.  What he said was 
> Most of the HTML document authors nowadays can ... generate a coordinate 
> out of an address with all the internet based address databases
> available.
>
Creating a coordinate out of an address is the conversion I referred to.
I said that conversion was a very bad idea, and gave the reason why it was a
bad idea.  He ignored my argument why conversion was a bad idea and told us
it was easy to convert.  I'd say Henning was correct.

You appear to be incorrect in saying conversion is not assumed.  On the
contrary, the geo is required and the civic is optional.  If you start with
a civic, you can optionally include it, but to geo-tag it, you need the
coordinates, and you get those by conversion with the databases Mr. Kaegis
mentions.

Nearly all of the location information available to an html document author
are street addresses.  To express a street address anywhere, you need a
complex data structure.  The IETF Geopriv working group undertook a very
large effort to create a data structure that works everywhere.  I suggested
that he use it, or supply a really good reason why a simpler structure would

Brian

> From: Martin Kofahl [mailto:[email-masked]]
> Sent: Friday, August 10, 2007 4:39 PM
> To: [email-masked]
> Subject: Re: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"
> 
> Dear Mr. Schulzrinne,
>