Re: Personal comments on latest editor's draft of POI Core

On 05/09/2011 10:32 AM, Thomas Wrobel wrote:
>
> +1 to decimal baring, that's pretty certain.
>
Yes, I see the draft has an issue about radians vs. degrees.  I won't 
comment about that, but even if degrees, it needs to be a decimal.
>
> " In a format to be recursively composed of <poi> elements from many
> sources, the likelihood of ID collisions is great."
>
> What do you mean by recursive in this context?
>
The <poi> element in the XML serialization has an "id" attribute.  In 
XML, attributes named "id" are almost always of type xsd:ID, which has 
restrictions on the lexical representation, and on the semantics.  If 
you do a query over a POI database for "Home" and obtain a result 
serialized as XML
<pois><poi id="home" /><poi id="home" />...</pois>
then that would violate the semantic requirement that each id attribute 
in the document be unique.

Also, the lexical requirement for ID excludes spaces, numeric first 
characters, and a bunch of other things, making this invalid:
<poi id="1. Tom's Place" />

The suggestion I made was to use a name attribute instead, so you are 
free to define your own syntax and semantics for it.  Then you can use 
name for the machine-readable name and label for the L10N label, and use 
this terminology consistently in the data definition and all serializations.

However, if you're looking to make the id be unique in the document, 
then using URIs as you suggest makes sense.  I saw some hints of that 
with "#" in some of the examples.  I'd suggest taking a look at the 
CURIE working draft which defines a straightforward way of dealing with 
the URI prefix problem.  (Briefly, it shows how to declare prefix 
definitions so you can say "eq:" is "http://earthquakes.usgs.gov" and 
then you can define your poi attribute to by a URI.)

While on this topic you might take a look at RDFa, which defines a set 
of attributes you can place on some other XML (or HTML) for adding in 
attributes such as "about", which might be good for this purpose instead 
of "id" or "name".  (RDFa has some measure of adoption on the web, being 
used in Google Site Maps and other such places.)

Leigh.


> If you mean the end client is likely to call in many POIs from
> different domains, thats something I agree with - but if the POI ID
> contains the domain it comes from (basically like any URI), surely it
> will always be unique ?
>
> You should be able to fully position one POI relative to a POI from
> another domain with an ID in this form. (say "place the mesh at this
> url at this position relative to this POIs uri")
>
> If, however, you mean the POI structure to be hiyarachal like a html
> file, with POIs and sub-POIs within them worked out meerly by the
> structure of the file itself - then Id urge strongly this should not
> be the way to do it. Not just due to ID collisions.
> Not everyone will be using xml, and not everyone will want to use http
> as the delivery method. Streams of POI data is usefull for some use
> cases, at other times dynamical collected POIs would be another. (so a
> search engine might find POIs that for fill a criteria-it doesn't want
> bundles, it needs self contained POIs).
>
> We thus shouldn't think too much like web coders here, and think more
> about the raw data needed to geolocate data and what key/value pairs
> to use for them. (nothing wrong with using xml as the examples though
> - just it shouldn't be assumed to be required)
>
> -Thomas
>
>
>
>
>
>
> ~~~~~~
> Reviews of anything, by anyone;
> www.rateoholic.co.uk
> Please try out my new site and give feedback :)
>
>
>
> On 6 May 2011 20:51, Leigh L Klotz Jr <leigh.klotz@xerox.com> wrote:
> > 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/
> >
>