made at this point, since the document is already in the RFC editor's
queue.
--Richard
On May 3, 2010, at 5:51 PM, Carl Reed wrote:
> And I have a number of comments and suggestions from the OGC
> Membership that I need to consolidate and submit. Some have to do
> with clarification of the CRS value definition and usage. This is
> important as some countries, such as China, have legal policies
> regarding CRS definitions for use in applications deployed in China.
> Nothing arbitrary at all.
>
> And Ivan, I have a hard time following your suggested edits and
> comments. Perhaps my email scrambled things.
>
> Regards
>
> Carl
>
> ----- Original Message ----- From: "Ivan Shmakov"
> <ivan@main.uusia.org>
> To: <geopriv@ietf.org>
> Sent: Monday, May 03, 2010 9:44 AM
> Subject: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>
>
> Glad to see that the specification have progressed further. I
> wonder, wouldn't it be too late to suggest a few more tweaks?
>
> --
> FSF associate member #7257
>
>
>
> --------------------------------------------------------------------------------
>
>
> --- www.ietf.org/id/draft-ietf-geopriv-geo-uri-07.xml 2010-04-14
> 23:31:04.000000000 +0700
> +++ draft-ietf-geopriv-geo-uri-07-1272900834.xml 2010-05-03
> 22:33:54.000000000 +0700
> @@ -99,7 +99,7 @@
> (WGS-84)</xref>. The scheme provides the textual
> representation of
> the location's spatial coordinates in either two or three dimensions
> (latitude, longitude, and optionally altitude for the default
> - CRS of WGS-84). An example of such an 'geo' URI follows:</t>
> + CRS of WGS-84). An example of such a 'geo' URI follows:</t>
> <vspace blankLines='1'/>
> <list style='hanging'>
> <t>geo:13.4125,103.8667</t>
> @@ -123,7 +123,7 @@
> intended to cope with the case of another CRS replacing WGS-84
> as the predominantly used one, rather than allowing the
> arbitrary
> use of thousands of CRSes for the URI (which would clearly
> affect
> - interopability). The definition of 'crs' values
> + interoperability). The definition of 'crs' values
> beyond the default of "wgs84" is therefore out of scope of
> this document.
> </t>
> @@ -203,11 +203,11 @@
> </artwork>
>
> <t>Parameter names are case insensitive, use of the lowercase
> - representation is PREFERRED. Case sensitivity of non-
> numeric
> + representation is preferred. Case sensitivity of non-
> numeric
> parameter
> values MUST be described in the specification of the
> respective parameter. For the 'crs' parameter, values are
> - case insensitive, and lowercase is PREFERRED.
> + case insensitive, and lowercase is preferred.
> </t>
> <t>Both 'crs' and 'u' parameters MUST NOT appear more than
> once each.
> @@ -370,7 +370,7 @@
> and their values are bitwise identical after percent-
> decoding.
> </t>
> <t>Otherwise, the comparison operation for the
> respective URIs
> - is undefined (since the legacy implementation is not
> + is undefined (since the legacy implementation would not
> be aware of the comparison rules for those parameters).
> </t>
> </list>
> @@ -382,7 +382,7 @@
> MUST NOT be considered equal to a URI containing a
> <coord-c>,
> even if the remaining <coord-a>, <coord-b>,
> - and their 'u' values are equivalent.
> + and 'u' values are equivalent.
> </t>
> <t>For the default CRS of WGS-84, the following comparison
> rules apply additionally:
> @@ -440,7 +440,7 @@
> <xref target='examples'/>.
> </t>
> </section>
> - <section anchor='uriinterop' title='Interopability Considerations'>
> + <section anchor='uriinterop' title='Interoperability
> Considerations'>
> <t>Like other new URI schemes, the 'geo' URI requires
> support in client applications. Users of applications which
> are
> not aware of the 'geo' scheme are likely not able to make
> direct use
> @@ -467,7 +467,7 @@
> locations.
> </t>
> <t>The number of digits in the <coordinates> values
> MUST NOT
> - be interpreted as an indication to a certain level of
> + be interpreted as an indication of a certain level of
> accuracy or uncertainty.
> </t>
> </section>
> @@ -495,7 +495,7 @@
> <t>This specification creates a new IANA Registry named
> "'geo' URI
> Parameters Registry" for the <parameter> component of
> the URI. Parameters for the 'geo' URI and values
> for these parameters MUST be registered with IANA to prevent
> - namespace collisions, and provide interopability.</t>
> + namespace collisions, and provide interoperability.</t>
> <t>Some parameters accept values that are constrained by a
> syntax
> definition only, while others accept values from a predefined
> set
> only. Some parameters might not accept any values at all
> ("flag"
> @@ -504,7 +504,7 @@
> that accept values from a predefined set.</t>
> <t>The specification of a parameter MUST fully explain the
> syntax,
> intended usage and semantics of the parameter. This ensures
> - interopability between independent implementations.</t>
> + interoperability between independent implementations.</t>
> <t>For parameters that are neither restricted to a set of
> predefined
> values nor of the "flag" type described above, the syntax of
> allowed values MUST be described in the specification, for example
> @@ -522,11 +522,11 @@
> <t>"No value": The parameter does not accept any values, and
> is to be used as a "flag" only.</t>
> <t>"Predefined": The parameter does accept values from a
> - predefined set only, as specified in a RFC or other
> permanent
> + predefined set only, as specified in an RFC or other
> permanent
> and readily available public specification.</t>
> <t>"Constrained": The parameter accepts arbitrary values
> that are only constrained by a syntax as specified in
> - a RFC or other permanent and readily available public
> + an RFC or other permanent and readily available public
> specification.</t>
> </list>
> </t>
> @@ -555,7 +555,7 @@
> </t>
> </list>
> </t>
> - <t>Note that the examples and use cases aboves as
> well as in
> + <t>Note that the examples and use cases above as well
> as in
> the next section are non-normative, and provided for
> information
> only.</t>
> </section> <!-- end of URI Operations section -->
> @@ -595,11 +595,11 @@
> <t>Resolution of the URI returns the following
> information:</t>
> <vspace blankLines='1'/>
> <list style='symbols'>
> - <t>The 'crs' is given in the URI, and sets the
> CRS used in the URI to WGS-84 explicitely.</t>
> + <t>The 'crs' is given in the URI, and sets the
> CRS used in the URI to WGS-84 explicitly.</t>
> <t>The URI does omit <coord-c>, is hence 2-
> dimensional, and therefore uses 'urn:ogc:def:crs:EPSG::4326' as the
> WGS-84 CRS identifier.</t>
> <t>The <coord-a> value (latitude in WGS-84)
> is set to '48.198634' decimal degrees.</t>
> <t>The <coord-b> value (longitude in
> WGS-84) is set to '16.371648' decimal degrees.</t>
> - <t>The <coord-c> (altitude) value is
> undefined, hence the client MAY assume the identified location to be
> on Earth's physical surface.</t>
> + <t>The <coord-c> (altitude) value is
> undefined, hence the client MAY assume the identified location to be
> on the Earth's physical surface.</t>
> <t>The 'u' parameter is included in the URI,
> setting
> uncertainty to 40 meters.</t>
> </list>
> @@ -870,7 +870,7 @@
> URIs with such values, and SHOULD warn the user when such
> URIs are encountered.
> </t>
> - <t>An example of such an URI referring to an invalid location
> + <t>An example of such a URI referring to an invalid location
> would be <geo:94,0> (latitude "beyond" north pole).
> </t>
> </section>
>
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
