W3C home > Mailing lists > Public > public-poiwg@w3.org > May 2011

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

From: Thomas Wrobel <darkflame@gmail.com>
Date: Mon, 9 May 2011 19:32:38 +0200
Message-ID: <BANLkTinvHMouOXrw+2+KnjH--DLv_9Y1Hw@mail.gmail.com>
To: Leigh L Klotz Jr <leigh.klotz@xerox.com>
Cc: public-poiwg@w3.org, mdw@w3.org
+1 to decimal baring, that's pretty certain.

" 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?

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)


Reviews of anything, by anyone;
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/
Received on Monday, 9 May 2011 17:33:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:29 UTC