Subject: [Geopriv] Review of draft-singh-geopriv-pidf-lo-dynamic-04

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 3 Nov 2008 23:55:07 -0600

Here is my review of draft-singh-geopriv-pidf-lo-dynamic-04.  

I've used an experimental XML format that is Richard's brainchild.  It should be fairly clear how to interpret it.  No promises, but software to process these documents might be forthcoming.

The cut-down version of the document is much more focused than previous documents.  This is a positive step - the document is much easier to review, previous versions were just too much to swallow in one lump.  That might have been why it was languishing from inattention.  I agree with the general approach of the document, but there are areas in its execution that could use improvement.   Thankfully, most of the improvements are in the detail.

I think that this work should be part of a new charter.  It solves an important problem and takes the right approach in doing so.  However, there is much to be improved before this gets published.

---

<comments about="http://tools.ietf.org/html/draft-singh-geopriv-pidf-lo-dynamic-04" by="mailto:[email-masked]" xml:lang="en">

  <comment id="abstractElements" section="abstract">
    <note>The last sentence is too specific and is too focused on the syntax, rather than the semantics.</note>
    <current-text>It defines five elements, namely speed, bearing, acceleration elevation and directionOfObject.</current-text>
    <proposed-text>Elements are defined that enable expression of speed, heading, acceleration and facing of the presentity.</proposed-text>
  </comment>

  <comment id="apresentity" section="1">
    <current-text>location of the presentity</current-text>
    <proposed-text>location of a presentity</proposed-text>
  </comment>

  <comment id="introreword" section="1">
    <current-text>However, a number of applications benefit from having access to information about changes in location.  Location change information is likely to be useful for logistics and public safety.  For example, shipping companies or dispatch centers can use it to track whether vehicles are deviating from an established path or exceeding speed limits. </current-text>
    <proposed-text>(new paragraph) The addition of rate of change information to the PIDF-LO enables a range of use cases.  These use cases either directly use dynamic information, or use that information for smoother tracking of a position over time.  For example, an application that continuously tracks a presentity could use velocity information to extrapolate positions in between times location information is measured.  A shipping company could directly use speed to monitor trucks speed to ensure speed limits are observed. (Big Brother wants to protect you from yourself.)</proposed-text>
  </comment>

  <comment id="ignoresafely" section="3">
    <note>You note that the temporal elements can be safely ignored.  However, the example shows that the location elements (Point, etc...) are in a different place to pdif-lo-profile.  Whether this is a problem depends on how an implementation interprets the document.  It's possible that it could be no problem, but it would be better to not leave this to chance.  (I should also add that gml:location is deprecated.)</note>
    <figure><![CDATA[
<!-- PIDF-LO profile: -->
<gp:location-info xmlns:gml="http://www.opengis.net/gml"
                  xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10">
  <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
    <gml:pos>-34.407 150.883</gml:pos>
  </gml:Point>
</gp:location-info>

<!-- PIDF-LO dynamic: -->
<gp:geopriv xmlns:gml="http://www.opengis.net/gml"
            xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10">
  <gp:location-info>
    <gml:location>
      <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
        <gml:pos>-34.407 150.883</gml:pos>
      </gml:Point>
    </gml:location>
    <gml:speed uom="#m/s">12</gml:speed>
    <!-- ... -->
  </gp:location-info>
</gp:geopriv>
    ]]></figure>
    <note>One disadvantage of any change is that the current approach is quite consistent with the GML design pattern.  It's just out of step with the approach already taken.
    </note>
    <note>The GML design pattern uses an alternating approach with properties (distinguished by the lower case element names) each tend to have a single value (there are some exceptions).  Properties with simple types include the value as text directly.  Properties with complex types include a single element that identifies the type of the content (DirectionVector or CompassPoint; capitalized name).  Each complex type has, in turn, a series of properties.</note>
    <note>To remain consistent with PIDF-LO profile (and to keep a loose sort of consistency with the GML approach), here is what I propose:
    </note>
    <figure><![CDATA[
<!-- PIDF-LO dynamic: -->
<gp:geopriv xmlns:gml="http://www.opengis.net/gml"
            xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10">
  <gp:location-info>
    <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
      <gml:pos>-34.407 150.883</gml:pos>
    </gml:Point>
    <dyn:Dynamic xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic">
      <gml:speed uom="#m/s">12</gml:speed>
      <gml:bearing>
        <gml:DirectionVector>
          <gml:vector>270.0 -60.0</gml:vector>
        </gml:DirectionVector>
      </gml:bearing>
    </dyn:Dynamic>
  </gp:location-info>
  <gp:usage-rules/>
</gp:geopriv>
    ]]></figure>
    <note>The dyn:Dynamic element is quite similar to the gml:MovingObjectStatus element.  The alternative was to use gml:MovingObjectStatus but that would mean that we'd have to specify gml:validTime and gml:position, which already have incompatible analogues in the existing schema.
    </note>
    <note>This is consistent with PIDF-LO profile rule #6 in that the two objects together form a complex.
    </note>
  </comment>

  <comment id="meatfocus" section="3">
    <note>This section seems to be the real meat of the document.  However, itlacks focus.</note>
    <current-text>This document defines a location vector by adding child elements to the &gt;location-info> element described in RFC 4119, to carry temporal feature elements.  A receiver MAY ignore the temporal elements defined in this document if it does not understand this extension.
    </current-text>

    <proposed-text>This document defines a new element, dyn:Dynamic, for the conveyance of dynamic information.  The dyn:Dynamic element contains information about the rate of change in the position of a presentity.  The dyn:Dynamic element MUST be included in the same gp:location-info element adjacent to the geodetic or civic location information that describes the instantaneous measured position of the presentity.  As an extension to the provided location information, dynamic information can be ignored if a recipient doesn't support this specification.

The dyn:Dynamic element contains the following components, each of which is optional:
    </proposed-text>
  </comment>

  <comment id="speeddef" section="3">
    <note>"Speed is the rate of motion." is true in a very imprecise way.  Given that the definition for speed is well known, either assume that the reader knows what it is and say nothing, or be VERY precise.  Promote the parenthetical.</note>
    <proposed-text>Speed is the time rate of change in position of a presentity without regard for direction.  Speed is the magnitude component of velocity.

The terms speed and velocity are often incorrectly used interchangeably.  Speed is a scalar value with only magnitude, whereas velocity is a vector with both magitude and direction.</proposed-text>
  </comment>

  <comment id="uomsection" section="3">
    <note>Don't be so vague on units of measure.  Devote a (small) section to the topic to introduce the concept and the new URNs (see 'uomdef' comment).  Then make each element very clear on what can be used.  Use MUST.
    </note>
    <note>This section can also include information on the inclusion of a CRS.</note>
  </comment>

  <comment id="speeduom" section="3">
    <note>Speed MUST be in m/s.  You can't make this mandatory in schema (unless you like breaking the rules for GML application schema), but you can make it mandatory in text.</note>
    <current-text>This element contains a 'uom' (Units Of Measure) attribute, which is a reference to a reference system for the amount.  The 'uom' attribute uses a URI to refer to a unit of measure definition.  The GML document defines a set of convenience measure types and a further explaination is provided at the end of this section.</current-text>
    <proposed-text>The value for speed MUST be defined in meters per second.  The speed element contains a uom attribute (see [UoM Section]) that MUST be set to "urn:.....#m/s".</proposed-text>
  </comment>

  <comment id="bearinguom" section="3">
    <note>Bearing doesn't have units of measure.  It should.  "urn:ogc:def:uom:EPSG::9102" is used in PIDF-LO profile and should be mandated here as well.  You also need to be careful with this element as it is dependent on the CRS/CS that you are using.  A two-dimensional CRS (e.g. EPSG 4326) has one dimension to the vector (Northing to Easting); a three-dimensional CRS (e.g. EPSG 4979) has two components.  Consistent with PIDF-LO profile, the CRS goes at the top and the UoM goes as far down as appropriate...</note>
    <figure><![CDATA[
<dyn:Dynamic srsName="urn:ogc:def:crs:EPSG::4979">
  <gml:bearing>
    <gml:DirectionVector>
      <gml:vector uom="urn:ogc:def:uom:EPSG::9102">
        270 -12
      </gml:vector>
    </gml:DirectionVector>
  </gml:bearing>
</dyn:Dynamic>
]]></figure>
  </comment>

  <comment id="velocity" section="3">
    <note>Does it make sense to have a bearing without a speed?  If dyn:Dynamic is a specially defined element, that gives the opportunity to bind the two together (force the inclusion of speed if bearing is specified).</note>
  </comment>

  <comment id="rapidacceleration" section="3">
    <note>Remove the parenthetical in the definition of acceleration.</note>
  </comment>

  <comment id="accelerationdirection" section="3">
    <note>Is the direction of acceleration the same as the direction of the velocity?  If so, make that clear and point out that this value is magnitude only.  Personally, I don't think it should use the same bearing as for velocity and this should have a matching directional attribute.</note>
  </comment>

  <comment id="directionOfObject" section="3">
    <note>I couldn't find a definition for directionOfObject anywhere in the GML document or schema.  Can I suggest that you using "facing" or something less vague?</note>
    <proposed-text>The "facing" element describes the orientation of the presentity; the direction that the face of the object is pointing.  This is specified as a directional vector using the same structure as "bearing".
    </proposed-text>
  </comment>

  <comment id="generalization" section="3">
    <note>After making lots of other comments about the existing elements, I'd like to question the current structure.  Taking a step back, it helps to see what is actually included here.  You have position (0th derivative), velocity (1st derivative) and acceleration (2nd derivative).
    </note>
    <note>Each component has a magnitude and orientation.  The 0th order term, position, is a little special, but thankfully, we've already got that sorted.  So, here we go on a restructure.</note>
    <figure><![CDATA[
    <dyn:Dynamic xmlns:dyn="...dyn" xmlns:gml="...gml"
                 srsName="...crsurn">
      <!-- 0th order; compass -->
      <dyn:facing>
        <gml:DirectionVector>
          <gml:vector uom="...deg">o1 o2</gml:vector>
        </gml:DirectionVector>
      </dyn:facing>

      <!-- 1st derivative of position -->
      <dyn:velocity> <!-- or just gml:speed -->
        <dyn:Velocity>
          <gml:speed uom="...m/s">speed</gml:speed>
          <gml:bearing>
            <gml:DirectionVector>
              <gml:vector uom="...deg">o1 o2</gml:vector>
            </gml:DirectionVector>
          </gml:bearing>
        </dyn:Velocity>
      </dyn:velocity>

      <!-- 2nd derivative (name?) -->
      <dyn:acceleration>  <!-- or just gml:acceleration -->
        <dyn:Acceleration>
          <gml:acceleration uom="...m/s/s">acc</gml:acceleration>
          <gml:bearing>
            <gml:DirectionVector>
              <gml:vector uom="...deg">o1 o2</gml:vector>
            </gml:DirectionVector>
          </gml:bearing>
        </dyn:Acceleration>
      </dyn:acceleration>

    </dyn:Dynamic>
    ]]></figure>
  </comment>

  <comment id="uomdef" section="3">
    <note>I've made comments in the past about the use of units of measure in previous versions of this document.  The value '#m/s' is interpreted by a GML parser as a URI, which means that it will attempt to find an ID attribute in the current document with the tag 'm/s' and that is of a type that extends gml:UnitDefinitionType.  Since this won't be true for PIDF-LO documents, what needs to be done is use a symbolic name here (i.e. a URN).  Unfortunately, I'm not aware of any symbolic names that are already defined for m/s and m/s/s (a noted omission from the document).</note>
    <note>So, as before, I'm going to recommend that this document simply define a URN for each new type and use those consistently.  This time I'll do the heavy lifting and provide a concrete piece of XML you can use.  If you identify the following document by a URN (e.g. urn:ietf:params:xml:ns:pidf:geopriv10:dynamic:uom), you can then use the units consistently and correctly (and--unfortunately--verbosely, e.g. "urn:ietf:params:xml:ns:pidf:geopriv10:dynamic:uom#m/s").</note>
    <note>Note that you don't really need the XML below, you can just define the necessary URNs.  But I've included it for reference.</note>
    <figure><![CDATA[
<!-- PIDF-LO dynamic: -->
<gml:Dictionary gml:id="unitsDictionary"
                xmlns:gml="http://www.opengis.net/gml">
  <gml:name>Dictionary of units required for dynamic location information.</gml:name>
  <gml:dictionaryEntry>
    <gml:BaseUnit gml:id="s">
      <gml:description>The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom.</gml:description>
      <gml:name>second</gml:name>
      <gml:quantityType>time</gml:quantityType>
    </gml:BaseUnit>
  </gml:dictionaryEntry>
  <gml:dictionaryEntry>
    <gml:BaseUnit gml:id="m">
      <gml:description>The metre is the length of the path travelled by light in vacuum during a time interval of 1/299 792 458 of a second.</gml:description>
      <gml:name>metre</gml:name>
      <gml:name xml:lang="en-US">meter</gml:name>
      <gml:quantityType>length</gml:quantityType>
      <!-- The metre is also identified by "urn:ogc:def:uom:EPSG::9001" -->
    </gml:BaseUnit>
  </gml:dictionaryEntry>
  <gml:dictionaryEntry>
    <gml:DerivedUnit xmlns:gml="http://www.opengis.net/gml"
                     gml:id="m/s">
      <gml:name>metres per second</gml:name>
      <gml:name xml:lang="en-US">meters per second</gml:name>
      <gml:quantityType>speed</gml:quantityType>
      <gml:derivationUnitTerm uom="#m" exponent="1"/>
            <gml:derivationUnitTerm uom="#s" exponent="-1"/>
    </gml:DerivedUnit>
  </gml:dictionaryEntry>
  <gml:dictionaryEntry>
    <gml:DerivedUnit xmlns:gml="http://www.opengis.net/gml"
                     gml:id="m/s/s">
      <gml:name>metres per second per second</gml:name>
      <gml:name xml:lang="en-US">meters per second per second</gml:name>
      <gml:quantityType>acceleration</gml:quantityType>
      <gml:derivationUnitTerm uom="#m" exponent="1"/>
      <gml:derivationUnitTerm uom="#s" exponent="-2"/>
    </gml:DerivedUnit>
  </gml:dictionaryEntry>
</gml:Dictionary>
    ]]></figure>
  </comment>

  <comment id="schema" section="4">
    <note>I don't believe that avoiding the definition of new schema objects is the correct approach for this document.</note>
  </comment>

  <comment id="deviceID" section="5">
    <note>The example does not include dm:deviceID, which is mandatory in dm:device element according to the RFC 4479 schema.</note>
  </comment>

  <comment id="uncertainty">
    <note>Uncertainty in the dynamic components might need to be considered.  ETSI TS 123.032 has some provision for this and I think that the restructure I proposed will help with that.  Let's sort out the other items first.  I'll look into how interoperability can be achieved later.</note>
  </comment>
</comments>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 7 Nov 2008 23:35:09 +0200

Hi Martin, 

Thanks for your detailed review comments.  

>I've used an experimental XML format that is Richard's 
>brainchild.  It should be fairly clear how to interpret it.  
>No promises, but software to process these documents might be 
>forthcoming.
>
>The cut-down version of the document is much more focused than 
>previous documents.  This is a positive step - the document is 
>much easier to review, previous versions were just too much to 
>swallow in one lump.  That might have been why it was 
>languishing from inattention.  I agree with the general 
>approach of the document, but there are areas in its execution 
>that could use improvement.   Thankfully, most of the 
>improvements are in the detail.
>
>I think that this work should be part of a new charter.  It 
>solves an important problem and takes the right approach in 
>doing so.  However, there is much to be improved before this 
>gets published.

Thanks for all the positive words about the updated version of the
document. 

>
>---
>
><comments 
>about="http://tools.ietf.org/html/draft-singh-geopriv-pidf-lo-d
>ynamic-04" by="mailto:[email-masked]" xml:lang="en">
>
>    <note>The last sentence is too specific and is too focused 
>on the syntax, rather than the semantics.</note>
>    <current-text>It defines five elements, namely speed, 
>bearing, acceleration elevation and directionOfObject.</current-text>
>    <proposed-text>Elements are defined that enable expression 
>of speed, heading, acceleration and facing of the 
>presentity.</proposed-text>
>  </comment>
>

Fixed. 

>    <proposed-text>location of a presentity</proposed-text>

Fixed. 

>    <current-text>However, a number of applications benefit 
>from having access to information about changes in location.  
>Location change information is likely to be useful for 
>logistics and public safety.  For example, shipping companies 
>or dispatch centers can use it to track whether vehicles are 
>deviating from an established path or exceeding speed limits. 
></current-text>
>    <proposed-text>(new paragraph) The addition of rate of 
>change information to the PIDF-LO enables a range of use 
>cases.  These use cases either directly use dynamic 
>information, or use that information for smoother tracking of 
>a position over time.  For example, an application that 
>continuously tracks a presentity could use velocity 
>information to extrapolate positions in between times location 
>information is measured.  A shipping company could directly 
>use speed to monitor trucks speed to ensure speed limits are 
>observed. (Big Brother wants to protect you from 
>yourself.)</proposed-text>
>  </comment>

Fixed. 

>    <note>You note that the temporal elements can be safely 
>ignored.  However, the example shows that the location 
>elements (Point, etc...) are in a different place to 
>pdif-lo-profile.  Whether this is a problem depends on how an 
>implementation interprets the document.  It's possible that it 
>could be no problem, but it would be better to not leave this 
>to chance.  (I should also add that gml:location is deprecated.)</note>
>    <figure><![CDATA[
>    <note>One disadvantage of any change is that the current 
>approach is quite consistent with the GML design pattern.  
>It's just out of step with the approach already taken.
>    </note>
>    <note>The GML design pattern uses an alternating approach 
>with properties (distinguished by the lower case element 
>names) each tend to have a single value (there are some 
>exceptions).  Properties with simple types include the value 
>as text directly.  Properties with complex types include a 
>single element that identifies the type of the content 
>(DirectionVector or CompassPoint; capitalized name).  Each 
>complex type has, in turn, a series of properties.</note>
>    <note>To remain consistent with PIDF-LO profile (and to 
>keep a loose sort of consistency with the GML approach), here 
>is what I propose:
>    </note>
>    <figure><![CDATA[
>    <note>The dyn:Dynamic element is quite similar to the 
>gml:MovingObjectStatus element.  The alternative was to use 
>gml:MovingObjectStatus but that would mean that we'd have to 
>specify gml:validTime and gml:position, which already have 
>incompatible analogues in the existing schema.
>    </note>
>    <note>This is consistent with PIDF-LO profile rule #6 in 
>that the two objects together form a complex.
>    </note>
>  </comment>

Fixed. 

>    <current-text>This document defines a location vector by 
>adding child elements to the &gt;location-info> element 
>described in RFC 4119, to carry temporal feature elements.  A 
>receiver MAY ignore the temporal elements defined in this 
>document if it does not understand this extension.
>    </current-text>
>
>    <proposed-text>This document defines a new element, 
>dyn:Dynamic, for the conveyance of dynamic information.  The 
>dyn:Dynamic element contains information about the rate of 
>change in the position of a presentity.  The dyn:Dynamic 
>element MUST be included in the same gp:location-info element 
>adjacent to the geodetic or civic location information that 
>describes the instantaneous measured position of the 
>presentity.  As an extension to the provided location 
>information, dynamic information can be ignored if a recipient 
>doesn't support this specification.
>
Fixed. 

>    <note>"Speed is the rate of motion." is true in a very 
>imprecise way.  Given that the definition for speed is well 
>known, either assume that the reader knows what it is and say 
>nothing, or be VERY precise.  Promote the parenthetical.</note>
>    <proposed-text>Speed is the time rate of change in 
>position of a presentity without regard for direction.  Speed 
>is the magnitude component of velocity.
>
>The terms speed and velocity are often incorrectly used 
>interchangeably.  Speed is a scalar value with only magnitude, 
>whereas velocity is a vector with both magitude and 
>direction.</proposed-text>
>  </comment>

I thought I copied it from the GML specification but maybe I messed it
up. 

Fixed. 

>    <note>Don't be so vague on units of measure.  Devote a 
>(small) section to the topic to introduce the concept and the 
>new URNs (see 'uomdef' comment).  Then make each element very 
>clear on what can be used.  Use MUST.
>    </note>

I don't think that a separate section is necessary. I folded the text
into the respective sub-sections. 

>    <note>Speed MUST be in m/s.  You can't make this mandatory 
>in schema (unless you like breaking the rules for GML 
>application schema), but you can make it mandatory in text.</note>
>    <current-text>This element contains a 'uom' (Units Of 
>Measure) attribute, which is a reference to a reference system 
>for the amount.  The 'uom' attribute uses a URI to refer to a 
>unit of measure definition.  The GML document defines a set of 
>convenience measure types and a further explaination is 
>provided at the end of this section.</current-text>
>    <proposed-text>The value for speed MUST be defined in 
>meters per second.  The speed element contains a uom attribute 
>(see [UoM Section]) that MUST be set to 
>"urn:.....#m/s".</proposed-text>
>  </comment>
>
Fixed. 

>    <note>Bearing doesn't have units of measure.  It should.  
>"urn:ogc:def:uom:EPSG::9102" is used in PIDF-LO profile and 
>should be mandated here as well.  You also need to be careful 
>with this element as it is dependent on the CRS/CS that you 
>are using.  A two-dimensional CRS (e.g. EPSG 4326) has one 
>dimension to the vector (Northing to Easting); a 
>three-dimensional CRS (e.g. EPSG 4979) has two components.  
>Consistent with PIDF-LO profile, the CRS goes at the top and 
>the UoM goes as far down as appropriate...</note>
>    <figure><![CDATA[

Fixed. 

>    <note>Does it make sense to have a bearing without a 
>speed?  If dyn:Dynamic is a specially defined element, that 
>gives the opportunity to bind the two together (force the 
>inclusion of speed if bearing is specified).</note>
>  </comment>

Fixed in context of your other comments. 

>    <note>Remove the parenthetical in the definition of 

Fixed. 

>    <note>Is the direction of acceleration the same as the 
>direction of the velocity?  If so, make that clear and point 
>out that this value is magnitude only.  Personally, I don't 
>think it should use the same bearing as for velocity and this 
>should have a matching directional attribute.</note>
>  </comment>

Fixed in context of your other comments. 
>    <note>I couldn't find a definition for directionOfObject 
>anywhere in the GML document or schema.  Can I suggest that 
>you using "facing" or something less vague?</note>
>    <proposed-text>The "facing" element describes the 
>orientation of the presentity; the direction that the face of 
>the object is pointing.  This is specified as a directional 
>vector using the same structure as "bearing".
>    </proposed-text>
>  </comment>

I thought I copied it from the GML specification but I searched for it
and couldn't find it either. 

Fixed. 

>    <note>After making lots of other comments about the 
>existing elements, I'd like to question the current structure. 
> Taking a step back, it helps to see what is actually included 
>here.  You have position (0th derivative), velocity (1st 
>derivative) and acceleration (2nd derivative).
>    </note>
>    <note>Each component has a magnitude and orientation.  The 
>0th order term, position, is a little special, but thankfully, 
>we've already got that sorted.  So, here we go on a restructure.</note>
>    <figure><![CDATA[

Sounds OK to me. 

>    <note>I've made comments in the past about the use of 
>units of measure in previous versions of this document.  The 
>value '#m/s' is interpreted by a GML parser as a URI, which 
>means that it will attempt to find an ID attribute in the 
>current document with the tag 'm/s' and that is of a type that 
>extends gml:UnitDefinitionType.  Since this won't be true for 
>PIDF-LO documents, what needs to be done is use a symbolic 
>name here (i.e. a URN).  Unfortunately, I'm not aware of any 
>symbolic names that are already defined for m/s and m/s/s (a 
>noted omission from the document).</note>
>    <note>So, as before, I'm going to recommend that this 
>document simply define a URN for each new type and use those 
>consistently.  This time I'll do the heavy lifting and provide 
>a concrete piece of XML you can use.  If you identify the 
>following document by a URN (e.g. 
>urn:ietf:params:xml:ns:pidf:geopriv10:dynamic:uom), you can 
>then use the units consistently and correctly 
>(and--unfortunately--verbosely, e.g. 
>"urn:ietf:params:xml:ns:pidf:geopriv10:dynamic:uom#m/s").</note>
>    <note>Note that you don't really need the XML below, you 
>can just define the necessary URNs.  But I've included it for 
>reference.</note>
>    <figure><![CDATA[
>      <gml:description>The second is the duration of 9 192 631 
>770 periods of the radiation corresponding to the transition 
>between the two hyperfine levels of the ground state of the 
>caesium 133 atom.</gml:description>
>      <gml:description>The metre is the length of the path 
>travelled by light in vacuum during a time interval of 1/299 
>792 458 of a second.</gml:description>

I am sure that someone defined the URLs/URNs already but I couldn't find
them. I am waiting for a response from Carl on this issue. 

>    <note>I don't believe that avoiding the definition of new 
>schema objects is the correct approach for this document.</note>
>  </comment>

This is an interesting aspect. 

I thought that just referencing the GML spec would be good enough and in
some sense it is a possible approach. 

However, when I tried to put the respective parts from the schema
together then I got the impression that it might be easier for
implementers to just have the relevant schema parts in the document and
then the entire story is done. 

That's what the new document is going to contain -- a new schema. 

>    <note>The example does not include dm:deviceID, which is 
>mandatory in dm:device element according to the RFC 4479 schema.</note>
>  </comment>

Fixed. 

>    <note>Uncertainty in the dynamic components might need to 
>be considered.  ETSI TS 123.032 has some provision for this 
>and I think that the restructure I proposed will help with 
>that.  Let's sort out the other items first.  I'll look into 
>how interoperability can be achieved later.</note>
>  </comment>

I am not so sure about the uncertainty aspect but we will see. 

Thanks a lot for your detailed comments. I am discussing with Henning on
how to appropriately acknowledge your contribution to the document. 

Here is the updated draft: 
http://www.tschofenig.priv.at/svn/draft-singh-geopriv-pidf-lo-dynamic/dr
aft-singh-geopriv-pidf-lo-dynamic-05.txt

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Nov 2008 17:10:50 -0600

Hi Hannes,

I'm impressed with how fast you've managed to produce such a large edit.

A few little things jumped out at me.

 - You've elected to clone the necessary parts from GML rather than referencing them.  I wouldn't have done that, but if you intend to keep this approach, there are a great many simplifications that can be gained.  For one, you can do away with all the UOM and CRS nonsense.  If you want some GML, I'd be happy to build you a compatible schema.

 - <facing> or <face>?

 - in the examples, you need to qualify the method element with the gp: ns prefix.  Timestamp goes after deviceID and is qualified with dm:.

 - (example 2 & 3) GPS doesn't typically give you acceleration or facing.  Of course, given a number of observations over time, you could derive acceleration, but the timestamp would start to become meaningless.

 - I didn't review the appendix before.  timed-status with from= and to= isn't suitable for instantaneous measurements of a continuous variable like location.  Multiple tuples (or device elements) are more applicable.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Saturday, 8 November 2008 8:35 AM
> To: Thomson, Martin; GEOPRIV
> Subject: Re: [Geopriv] Review of draft-singh-geopriv-pidf-lo-dynamic-04
> 
> Hi Martin,
> 
...