+++ 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>
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
