Personal comments on latest editor's draft of POI Core

I have some comments on the latest editor's draft prior to its formal 
release as FPWD [1]
Although I am co-chair of the W3C Forms WG, these are my personal comments.

1. Consideration of existing efforts
Have you considered RFC 5870, which proposes a URI scheme for locations 
("Geo URI")?  It could give you a URI representation for the latitude 
and longitude attributes which are currently separate.

Did you also consider alternatives to latitude and longitude, such as 
Maidenhead grid (a human-readable alphanumeric compression which offers 
progressive precision, useful for privacy). 
http://en.wikipedia.org/wiki/Maidenhead_Locator_System

Also I was surprised to see no reference toGPX, an XML format for 
waypoints, either as a reference or in comparison for why a new model 
and format is needed.

2. XML Notation Section 4.1
It might make more sense to normatively reference the definitions in XML 
Schema Part 2 Datatypes for these definitions of leaf-node data types 
instead of attempting to define them normatively here.

3. Formal definition of XML format
Please consider publishing a RelaxNG Compact syntax definition.  It 
would be quite readable, and would help give clarity to your model as it 
develops.  A number of XML tools (Java, Oxygen, NXML, Jing) are able to 
validate XML documents against an RNC schema.  I've attached a sample 
one back-formed from your example XML as an indicator of how readable it 
could be.  It's not 100% accurate, but it does validate the attached 
example and would serve as a starting point for you.  I'd recommend 
publishing the schema in non-normative URI space (/poi) and adding it as 
an informative reference; that way you can update it as necessary, and 
leave the prose as the normative definition in /TR space.

4. XML Example
It would be nice to clean up the XML example before FPWD, so it's at 
least well-formed.
A schema could automate this process, and help you validate your changes 
to the format and to examples or test cases.

5. Use of id attributes.
Please carefully consider use of ID attributes, since they must be 
unique in a document.  In a format to be recursively composed of <poi> 
elements from many sources, the likelihood of ID collisions is great.  
It might be better to use a name attribute instead, and specify in prose 
the scope of name to be a single poi.

6. label primary attribute
What is the rationale for using a primary attribute on label instead of 
document order?  Even if you have other serializations of the model, 
they surely all support ordered lists.

7. address
The international address definition problem is unlikely to be easily 
solved in this document.

8. bearing
bearing should be decimal, not integer.

9. Language
Both xml:lang and MARC alpha 3 language codes are used.  You should pick 
one.  xml:lang is easier to refer to normatively, because ISO 
publication normative references can be problematic for implementors due 
to cost.  Perhaps Martin Duerst has a comment on this.

10. Time and duration
I'd recommend taking a look at the XML Schema Part 2 Datatypes, which 
profiles ISO 8601, making it easy for you to cite it as a normative 
reference.  For durations, take care to note that day-date durations are 
not inter-comparable with month-year durations.

11. point order
The XML serialization has no need to represent an ordered list of points 
with an integer order attribute.  Just define your model as requiring 
the preservation of order, and leave it to serializations to decide how 
to do it. JSON and XML have no need for this non-normalized order number 
which just makes processing harder for consumers of the document format.

12. map side
I'm not certain about map side's definition, but "left" | "right" | 
"end" seems like it does not encompass other common locations relative 
to streets: please consider "median" and "above" and "below".

Thank you,
Leigh.

[1] http://www.w3.org/blog/POI/2011/05/03/poi-core-editors-draft-released/