Subject: [Geopriv] [geopriv] #17: Text nits by Ivan Shmakov

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 02 Sep 2009 15:35:26 -0000

#17: Text nits by Ivan Shmakov
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement                 |      Status:  new                       
 Priority:  trivial                     |   Milestone:                            
Component:  geo-uri                     |     Version:                            
 Severity:  -                           |    Keywords:                            
----------------------------------------+-----------------------------------
 Please consider the following patch.

         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 (-, &#x2d, HYPHEN-MINUS)
           is used instead of a proper M-dash (&#x2014, 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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/17>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Mon, 21 Sep 2009 08:23:59 -0000

#17: Text nits by Ivan Shmakov
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]  |        Owner:  [email-masked]
     Type:  enhancement                 |       Status:  closed                    
 Priority:  trivial                     |    Milestone:                            
Component:  geo-uri                     |      Version:                            
 Severity:  -                           |   Resolution:  fixed                     
 Keywords:                              |  
----------------------------------------+-----------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 added changes to -03 version.

-- 
Ticket URL: <http://tools.ietf.org/wg/geopriv/trac/ticket/17#comment:1>
geopriv <http://tools.ietf.org/geopriv/>