RE: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"

I have a few comments:

I'd like to suggest location by reference for those who need, or would like to have, the extra flexibility available in PIDF-LO.  All you need to do is define a geo.reference tag that includes a URI.  Leave the details of resolving this URI to the client.  This would also address some of your acknowledged limitations.

RFC 4776 doesn't define any strings like "a1", "a2", "lmk", etc...  You really want revised civic.  I don't understand your reluctance to reference a document that is past IETF last call in an individual submission.  Referencing 4776 or revised civic should mean that you don't need to describe the contents of the fields.  That means you can drop a few paragraphs and your reference ISO 3166 (Section 3).

I'd like to see this draft consistent with standard XML data format practice for lists.  You use ';' as a separator for geo.position, but I'd suggest that a space is more consistent with other XML applications.  This would improve compatibility with GML/PIDF-LO.

I like the comment about the street entrance, but I'm not sure that your point on "accuracy" is quite right.  Read draft-thomson-geopriv-uncertainty for a discussion on using "accuracy" as a qualitative term.  You probably meant to say that the point SHOULD be within 10 metres of the actual location.  It might be better to say that the intent is that a user is able to take the coordinates and find what they are looking for.  To that end, the location only needs to be as accurate as it needs to be to achieve that goal.

Since this is an internet draft, Section 3.1 is a bit redundant.

I think that you need to include xml:lang in Section 7.

Section 5 can be greatly reduced in size if you provide a reference to GML (see opengeospatial.org).  A much shorter tutorial would simply state that latitude and longitude are defined in decimal degrees and that altitude is in metres above the geoid.

Avoid the use of the word "precision" (c.f. uncertainty draft above).

Your ABNF in Section 6 needs to reference RFC 4234 and there are quite a few redundant lines that could be removed.

The last example in Section 4 is missing ``content=''.

You talk about features that can't be described by a point.  Ironically, the civic address doesn't suffer from this problem.  Adding location by reference would address this.  That is, having a link to a PIDF-LO document would be useful where the extra detail could be useful.

Check spelling - there are quite a few typos: http://tools.ietf.org/tools/idspell/webservice

That's all I could come up with in 15 minutes.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Daviel [mailto:advax@triumf.ca]
> Sent: Thursday, 15 November 2007 1:07 PM
> To: Tschofenig, Hannes (NSN - DE/Munich)
> Cc: geopriv@ietf.org; Henning Schulzrinne
> Subject: Re: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"
> 
> On Thu, 27 Sep 2007, Tschofenig, Hannes (NSN - DE/Munich) wrote:
> 
> >> If I resubmit draft-daviel-html dropping geo.region and
> >> geo.placename and
> >> adding the PIDF fields as above, would this be acceptable?
> >
> > These change look promising to me.
> >
> >
> 
> Done.
> 
> Probably not the best reference for PIDF; I used somewthing with RFC
> status rather than the current draft.
> 
> http://www.ietf.org/internet-drafts/draft-daviel-html-geo-tag-08.txt
> 
> I note in passing that there's another position metadata in current use,
> viz.
> <meta name="ICBM" content="40.757929, -73.985506" />
>   - at least it's decimal degrees in WGS84
> 
> --
> Andrew Daviel, TRIUMF, Canada
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]