Subject: [Geopriv] Some comments on draft-ietf-geopriv-policy-06

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Aug 2005 14:53:27 +1000

I have had some time to go over this document and I have some concerns.  On
the whole the document is good, however I think that there are a few things
that could be improved.

I see statements like the following in a number of drafts:

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
       "urn:ietf:params:xml:ns:common-policy cp02.xsd
        urn:ietf:params:xml:ns:geopriv-policy gp03.xsd">

     <xs:import namespace="urn:ietf:params:xml:ns:common-policy"
       schemaLocation="20050421common-policy-05.xsd"/>

Is there an accepted practice for the name of schema files?  I understand
that an import requires a value, so I guess that there might be.  I would,
however, strong suggest that the xsi:schemaLocation parameter be removed - I
use it for testing schema when I develop them, but in practice it will be
ignored, the schema location is not something that you want defined.

The polygon and altitude definitions here seem to be duplicated from the GML
specification, which seems contrary to the decisions made for PIDF-LO.  If a
processor has to understand GML, then why introduce yet another format for
essentially the same thing?  PIDF-LO profile includes a good example of a
polygon if that is the problem.

A second aspect of this is the re-definition of another CRS URN:
"urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84".  Aside from the fact that
the CRS is assumed to be a 2D CRS with latitude and longitude, it would be
beneficial to have a standardized CRS URN and avoid having to understand a
number of different schemes.  Altitude is apparently separate to this (I
understand the limitations of 2D shapes and so forth, but I believe that
there are better ways to describe bounding conditions).

This actually leads into a more interesting problem, that is a means for
describing a bounding area.  If GML were used there would be an opportunity
to describe an area as a volume, a circle, or a polygon as needs demand.
The problem of mismatch (that is, comparing two different CRSs) is no worse
by including GML at both ends, indeed it makes it easier to avoid (the rules
can use the same CRS as the location).

<gp:lat-resolution> and <gp:lon-resolution> should be changed to something
that mimics the way that <gml:point> is defined, that is, something like:

  <gp:resolution srsName="urn:ogc:def:crs:EPSG:6.6:4326">
    0.2 0.1
  </gp:resolution>

...which would easily enable arbitrary CRSs.

Your dilution of precision section makes no comments about how locations of
different types - polygon/circle/etc.. might be transformed.  I'd imagine
that the procedure can be applied to polygons by applying the procedure to
each point, but a circle might also require some operation on the radius.

Civic transformations might be better specified as a set of XPath selectors,
or even just a list of allowed element names.  You can predefine #full as a
list that contains everything, and #city as "country A1 A2" to make it
easier on people.  The problem with the existing set is that it does not
consider alternate civic formats and any additions to the civic address
format that may become standard (or de-facto standard).

<civic-loc-condition> doesn't allow for alternate civic types.  I refer here
to http://www.ietf.org/internet-drafts/draft-thomson-revised-civic-lo-00.txt
It might be better to allow for civicAddress/civilAddress as element content
of this element.

No mention is made of conditions for composite civic-geo locations.  I would
assume that a rule must exist for both, but this might be difficult for
incomplete civic location components (for instance, floor number only).

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