Among the issues I've considered:
* the name of the planet Earth is constantly uncapitalized; (or
is it written this way for a purpose? or is there something I
don't understand?)
* actually, I don't know why a hyphen (-, -, HYPHEN-MINUS)
is used instead of a proper M-dash (—, EM DASH), but I
guess that there's some implementation restriction justifying
that; anyway, <workgroup> has the M-dash encoded with two
hyphens instead (--), so I changed all the other instances to
match;
* the names of the parameters are written both single-quoted
('u') and double-quoted ("u"); as I didn't know whether this
was done on a purpose, I've left it that way;
* one more nitpick: the whitespace is a bit weird; namely,
blanks and TABs (ASCII: HT, code 9) are somewhat mixed, and
there're a plenty of lines which end with a sequence of
blanks, or are comprised of blanks entirely; as it makes no
difference to the XML parser, I've left it that way, too.
I guess, it will be found that not all of the edits below are
actually necessary.
--- draft-ietf-geopriv-geo-uri-02.xml~ 2009-09-01 19:39:48 +0700
+++ draft-ietf-geopriv-geo-uri-02.xml 2009-09-02 22:00:02 +0700
@@ -78,7 +78,7 @@
open source mapping community brought an enormous momentum into
location aware technology.
A wide range of tools and data sets which formerly were accessible
- to professional only became available for a wider audience.
+ to professional users only became available for a wider audience.
</t>
<t>The 'geo' URI scheme is another step into that direction and aims
to facilitate, support and standardize the problem of location
@@ -86,7 +86,7 @@
in geospatial services and applications. Accessing information about
a particular location on earth or trigger further services
shouldn't be any harder than clicking on a 'mailto:' link
- and write an email straight away.
+ and writing an email straight away.
</t>
<t>According to <xref target='RFC3986'/>, a Uniform Resource Identifier (URI)
is "a compact sequence of
@@ -105,7 +105,7 @@
inclusion of arbitrary URIs.</t>
<t>For the sake of usability, the definition of the URI scheme
is strictly focused on the simplest, but also most common
- representation of a spatial location - a single point in a well
+ representation of a spatial location -- a single point in a well
known CRS. The
provision of more complex geometries or locations described by
civic addresses is out of scope of this document.
@@ -118,7 +118,7 @@
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
- beyond the default of "wgs84" is therefore out of scope of
+ beyond the default of "wgs84" is therefore out of the scope of
this document.
</t>
<t>Note: The choice of WGS-84 as the default CRS
@@ -215,7 +215,7 @@
</section>
<section anchor='urisemantics' title='URI Scheme Semantics'>
<t>Data contained in a 'geo' URI identifies
- a physical resource: A spatial location on earth
+ a physical resource: a spatial location on Earth
identified by the geographic coordinates encoded in the URI.
</t>
<section anchor='crsidentification' title='Coordinate Reference System Identification'>
@@ -288,7 +288,7 @@
<section anchor='uncertainty' title="Location Uncertainty">
<t>The 'u' ("uncertainty") parameter indicates the amount of
uncertainty in the location as a value in meters. Where a
- geo URI is used to identify the location of a particular
+ 'geo' URI is used to identify the location of a particular
subject, uncertainty indicates the uncertainty with which
the identified location of the subject is known.
</t>
@@ -298,7 +298,7 @@
specific point in space, uncertainty MAY be set to zero.
Zero uncertainty and absent uncertainty are never the same thing.
</t>
- <t>Note: The number of significant digits of the value
+ <t>Note: The number of digits of the values
in the 'coordinates' component MUST NOT be interpreted
as an indication to uncertainty.</t>
</section>
@@ -330,7 +330,7 @@
An URI with undefined (missing) 'coord-c' (altitude) value
MUST NOT be considered equal to an URI containing an
'coord-c' value,
- even if the remaining values 'coord-a', 'coord-b' and 'u'
+ even if the remaining 'coord-a', 'coord-b' and 'u' values
are equivalent.
</t>
</section>
@@ -338,7 +338,7 @@
<t>A consumer of a 'geo' URI in the WGS-84 CRS with undefined 'altitude' MAY
assume that the URI refers to the respective location on earth's
physical surface at the given 'latitude' and 'longitude'
- coordinate.
+ coordinates.
</t>
<t>However, as defined above, altitudes are relative to the WGS-84
reference geoid rather than earth's surface. Hence, an altitude
@@ -350,7 +350,7 @@
</section>
<section anchor='urienc' title='Encoding Considerations'>
<t>The 'coordinates' path component of the 'geo' URI
- (see <xref target='urisyntax'/>) uses a comma (",") as a
+ (see <xref target='urisyntax'/>) uses a comma (",") as the
delimiter for subcomponents. This delimiter MUST NOT be
percent encoded.
</t>
@@ -361,7 +361,7 @@
</t>
<t>Regarding internationalization, the currently specified
components do allow for ASCII characters exclusively,
- and therefore don't require internationalization-
+ and therefore don't require internationalization.
Future specifications of
additional parameters might allow for introduction of non-ASCII
values. Such specifications MUST describe internationalization
@@ -379,9 +379,9 @@
<section anchor='uriinterop' title='Interopability 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 unable to make direct use
+ not aware of the 'geo' scheme are likely to be unable to make direct use
of the information in the URI. However, the simple structure of the
- 'geo' URI would even allow manual dereference by humans.
+ 'geo' URI would allow even manual dereference by humans.
</t>
<!-- <t>Malformed and invalid 'geo' URI instances could contain whitespace
and values with leading plus signs ("+"), which is not allowed
@@ -466,8 +466,8 @@
</t>
</section>
<section anchor='uriops' title="URI Operations">
- <t>Currently, just one operation on a 'geo' URI is defined - location
- dereference: In that operation, a client dereferences the URI by
+ <t>Currently, just one operation on a 'geo' URI is defined -- location
+ dereference. In that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component
('geo-path' in the ABNF).
Further use of those coordinates (and the uncertainty value from
@@ -487,7 +487,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 -->
@@ -559,14 +559,14 @@
<t>The Geographic Markup Language (GML) by the Open Geospatial
Consortium (OGC) is a set of XML schemas
to represent geographical features. Since GML is widely accepted,
- this document includes instructions on how to transpose 'geo' URIs
+ this document includes instructions on how to transform 'geo' URIs
from and to GML documents. The instructions in this
section are not normative.
</t>
<t>
For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
placeholders for latitude, longitude, altitude and uncertainty
- values. The mappings use WGS-84, and are defined in the following sections.
+ values, respectively. The mappings use WGS-84, and are defined in the following sections.
</t>
<t>Note: GML documents in other reference systems could be used as
well if a transformation into "urn:ogc:def:crs:EPSG::4979" or
@@ -575,7 +575,7 @@
</t>
<t>GML uses the 'double' type from XML schema, and the mapping
examples assume that numbers in the form of "3.32435e2" in GML
- are properly converted to decimal when placed in the 'geo' URI.
+ are properly converted to decimal when placed into the 'geo' URI.
</t>
<section anchor='2dpoint' title="2D GML 'Point'">
<t>A 2D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty ("u") parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
@@ -726,7 +726,7 @@
</section>
<section anchor='locprivacy' title='Location Privacy'>
<t>A 'geo' URI by itself is just an opaque reference to a
- physical location, expressed by a set of spatial oordinates. This
+ physical location, expressed by a set of spatial coordinates. This
does not fit the "Location Information" definition according to
Section 5.2 of <xref target='RFC3693'>GEOPRIV Requirements</xref>,
because there is not necessarily a "Device" involved.
@@ -734,13 +734,13 @@
<t>
Because there is also no
way to specify the identity of a "Target" in a 'geo' URI by
- itself, it does also not fit the
- specification of an "Location Object" (Section 5.2 of RFC3693).
+ itself, it also does not fit the
+ specification of a "Location Object" (Section 5.2 of RFC3693).
</t>
<t>However, by putting a 'geo' URI into a context that allows
identification of a "Target", the URI might become part of a
- "Location Object", and would then be subject to GEOPRIV rules.</t>
- <t>Therefore, Publishers of 'geo' URIs that are put into such
+ "Location Object", and would then be subject to the GEOPRIV rules.</t>
+ <t>Therefore, publishers of 'geo' URIs that are put into such
contexts MUST consider privacy issues, particularly in cases where
a URI instance is combined with Personally Identifyable Information
(PII) with the intent to describe the location of a Target that
@@ -754,7 +754,7 @@
<t>The authors further wish to acknowledge the helpful
contributions from Carl Reed,
Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders,
- Ted Hardie, Culllen Jennings, Klaus Darilion and Bjorn Hoehrmann.
+ Ted Hardie, Cullen Jennings, Klaus Darilion and Bjorn Hoehrmann.
</t>
</section>
</middle>
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
