[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
INTERNET-DRAFT                                          Mari Korkea-aho
draft-korkea-aho-spatial-location-payload-00.txt            Haitao Tang
Expires: November 2001                                            Nokia
                                                               May 2001


                        Spatial Location Payload
          < draft-korkea-aho-spatial-location-payload-00.txt >


Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as 'work in progress.'

The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.



Abstract

   This document defines the syntax and coding for the spatial location
   payload, which can hold various spatial location data sets.



1. Introduction

   There are very many different ways of representing location
   information and different location-based applications can require
   different spatial location data. [1]

   This document defines a common Spatial Location Payload, to carry any
   spatial location data set, e.g., the common spatial location defined
   in [1], the descriptive location defined in [2], or any other
   location data.

   The advantage of the Payload is that there will be a general way of
   expressing different location data sets, enabling interoperability
   and use of common tools. In addition, the Payload will e.g. enable a
   location to be expressed in many different ways, or combining
   different location data sets (e.g. the common spatial location data
   set SLO [1] and some application specific extensions).



Internet Draft             Spatial Location Payload            May 2001


   2. Spatial Location Payload Structure

   The Payload can include any number of location data sets (Fig. 1.)
   and their associated elements. It could e.g. contain the common
   spatial location set SLO [1] and some application specific extensions
   to SLO.

   (Note: Instead of combining the common spatial location set SLO and
   the application specific extensions in the Payload, SLO and the
   extensions can be defined as a common data set using DTD or XML
   Schema extension mechanisms [1]. However, in order to simplify
   translation and processing we recommend defining extensions as own
   separate data sets).


   +-Payload-----------------+           +-Payload-----------------+
   |                         |           |                         |
   | +---------------------+ |           | +---------------------+ |
   | | Elements of         | |           | |                     | |
   | | location data set 1 | |           | |SLO data elements [1]| |
   | +---------------------+ |           | |                     | |
   |                         |    e.g.   | +---------------------+ |
   | +---------------------+ |           |                         |
   | | Elements of         | |           | +---------------------+ |
   | | location data set 2 | |           | |                     | |
   | +---------------------+ |           | | Extensions to SLO   | |
   |                         |           | |                     | |
   | +---------------------+ |           | +---------------------+ |
   | | Elements of         | |           |                         |
   | | location data set n | |           +-------------------------+
   | +---------------------+ |
   |                         |
   +-------------------------+

   Figure 1. Payload structure and example


3. Syntax of Spatial Location Payload

   The syntax is specified with ABNF grammar (RFC2234). Further
   explanation and example are given in the next section.

   ====================================================================
   Spatial-Location-payload = *(Location-Content Delimiter)

   Location-Content = Coordinate-Location | Descriptive-Location | Any-
   Other-Location

   Coordinate-Location = <any coordinate-centered location>

                         ; e.g., those defined in [1, 3-7], while the

M. Korkea-aho, H. Tang                                         [Page 2]


Internet Draft             Spatial Location Payload            May 2001


                         ; common spatial location data set [1] is
                         ; recommended to be when there is no other
                         ; mutually understood/preferred location format
                         ; between the involved parties

   Descriptive-Location = <any description-based location>

                         ; e.g., a descriptive location define in [2]

   Any-Other-Location = <any other location information>

   Delimiter = <any character or string serving as a delimiter between
                elements>

                         ; e.g., when using XML-based coding, it
                         ; "is" a pair of corresponding element
                         ; tags
   ====================================================================


4. Coding Spatial Location Payload with XML

   The location Payload could be encoded in many different ways, e.g.,
   text based attribute-value pairs, binary, MIME, XML, etc. In order to
   enable interoperability, we need a common way for coding the payload.

   We propose XML. The advantages of XML are that the encoding is easily
   understandable and human readable. Standard tools and parsers can be
   used. In addition, many of the other proposals make use of XML, while
   a possible disadvantage of using XML is that it is quite verbose.

4.1 DTD-based solution

   For the correct parsing, we need only those DTDs defined for the
   different location elements carried in the payload. Here is an
   example case of a spatial location payload. It carries two element
   sets, SLO [1] and a descriptive location data set dls-finnish1 [2].

   Example XML Payload message using DTDs:
   ====================================================================
   <?xml version="1.0" encoding = "UTF-8"?>
   <!DOCTYPE Location-Payload [
   <!ENTITY % slo-default-dtd PUBLIC "-//IETF//SLO-Default//EN"
   "http://www-nrc.nokia.com/ietf-spatial/2001/05/08/slo_default.dtd">
   <!ENTITY % dls-finnish1-dtd PUBLIC "-//FIN//DESCRIPTIVE-Location//EN"
   "http://www-nrc.nokia.com/ietf-spatial/2001/05/08/dls-finnish1.dtd">
   %slo-default-dtd;
   %dls-finnish1-dtd;
   <!ELEMENT Location-Payload (SLO, dls-finnish1)>
   ]>
   <Location-Payload>

M. Korkea-aho, H. Tang                                         [Page 3]


Internet Draft             Spatial Location Payload            May 2001


   <SLO>
     <POS>
       <LAT>N60.08.00.235556</LAT>
       <LONG>E025.00.00</LONG>
     </POS>
     <ALT>+12.99</ALT>
     <ALT_MSL>010</ALT_MSL>
     <H_ACC>50</H_ACC>
     <V_ACC>2.5</V_ACC>
     <TIME>2001-01-01T12:00:01+02:00</TIME>
   </SLO>
   <dls-finnish1 DL-Type="featured" Charaset="UTF-8" Time="unknown">
     <f1-level1>
       <Street>Samitie 8</Street>
       <Apartment>D 35</Apartment>
     </f1-level1>
     <f1-level2>
       <Postal-code>00900</Postal-code>
       <Metropolitan-Area>Helsinki</Metropolitan-Area>
     </f1-level2>
     <Country>Finland</Country>
   </dls-finnish1>
   </Location-Payload>
   ====================================================================

   In order to avoid conflicts in the payload, the elements of the
   different location data sets in the payload should be unique. This
   can be achieved by using XML namespaces [8].


4.2 XML Schema-based solution

   For the correct parsing, we need only the XML schemas defined for the
   different location elements carried in the payload. Here is an
   example. It carries two element sets, SLO [1] and a data set "car" of
   an imaginary car application (see Appendix A.2 for XML schema).

   Example XML Payload message using XML schemas:
   ====================================================================
   <?xml version = "1.0" encoding = "UTF-8"?>
   <Location-Payload>
   <loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/location"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/location http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/location.xsd">
     <POS>
       <LAT>N60.08.00.235556</LAT>
       <LONG>E025.00.00</LONG>
     </POS>

M. Korkea-aho, H. Tang                                         [Page 4]


Internet Draft             Spatial Location Payload            May 2001


     <ALT>+12.99</ALT>
     <ALT_MSL>010</ALT_MSL>
     <H_ACC>50</H_ACC>
     <V_ACC>2.5</V_ACC>
     <TIME>2001-01-01T12:00:01+02:00</TIME>
     <G_SPEED>2.0</G_SPEED>
     <V_SPEED unit="knot">1</V_SPEED>
     <DIR>M240</DIR>
     <COURSE>M30</COURSE>
     <H_ORIENT>T25</H_ORIENT>
     <V_ORIENT>179</V_ORIENT>
   </loc:SLO>
   <car:car-data xmlns:car="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/car" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
   instance" xsi:schemaLocation="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/car http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/car.xsd">
     <car_orientation>
       <x>360</x>
       <y>40</y>
       <z>20</z>
     </car_orientation>
     <hardware>
       <gps>
         gps4everyone
       </gps>
     </hardware>
   </car:car-data>
   </Location-Payload>
   ====================================================================


5. Naming of Data Sets

   If each data set has a unique identifier, the different data sets can
   be identified. This simplifies the processing and possible
   transformation between different representation formats.

   In the Payload the different data sets are currently identified by:

   a) in the DTD-based solution: the DTD URI or public identifier.

   b) in the Schema-based solution: the Schema URI or namespace.


6. Other Considerations

   Security. Location alone usually means nothing but a "point"
   somewhere. However, when associated with a meaningful target such as
   a person, the location is potentially private or sensitive even
   though some parties may like to release their location information to

M. Korkea-aho, H. Tang                                         [Page 5]


Internet Draft             Spatial Location Payload            May 2001


   the public. The authors believe that there must be security
   mechanisms available to protect the information whenever needed.
   However, we let the location-dealing applications or protocols define
   or select their own specific mechanisms for authorization,
   authentication, encryption, key exchanging, etc.


7. References

   [1] M. Korkea-aho, et al., "A Common Spatial Location Dataset," IETF
   Draft (draft-korkea-aho-spatial-dataset-01.txt), Work in progress,
   May 2001.

   [2] H. Tang, et al., "Common Syntax and Coding for Descriptive
   Location," IETF Draft (draft-tang-spatial-descriptive-location-
   00.txt), Work in progress, May 2001.

   [3] 3rd Generation Partnership Project, Technical Specification Group
   Core Network, Universal Geographical Area Description(GAD), Release
   1999, Technical Specification, 3G TS 23.032 V3.1.0 (2000-03).

   [4] Definition of a Mobile Location Query API, Contribution to
   Location Inter-operability Forum (LIF), API Specification, v.0.5, 18
   Oct 2000.

   [5] Lake, R., Cuthbert, A. (eds.), Geography Markup Language (GML)
   v1.0, OGC Document Number: 00-029, 12-May-2000,
   http://www.opengis.org/techno/specs/00-029.pdf.

   [6] Sekiguchi, et al., NaVigation Markup Language (NVML),  W3C Note 6
   Aug 1999,http://www.w3.org/TR/NVML.

   [7] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest
   eXchange Language Specification,  W3C Note - 24 June 1999,
   http://www.w3.org/TR/poix.

   [8] Bray et al., Namespaces in XML, World Wide Web Consortium 14
   January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114

   [9] Fallside, D. (Ed.), XML Schema Part 0: Primer, W3C
   Recommendation, May 2001, http://www.w3.org/TR/xmlschema-0/



Author's Addresses

   Mari Korkea-aho
   P.O. Box 407, FIN-00045 Nokia
   Finland
   Email: mari.korkea-aho@iki.fi


M. Korkea-aho, H. Tang                                         [Page 6]


Internet Draft             Spatial Location Payload            May 2001


   Haitao Tang
   P.O. Box 407, FIN-00045 Nokia
   Finland
   Email: haitao.tang@nokia.com



Appendix A.1

   XML DTD for a set of location elements of an imaginary car
   application.

   <!-- car.dtd -->
   <!ELEMENT car (car_orientation, hardware?)>
   <!ELEMENT car_orientation (x, y, z)>
   <!ELEMENT x (#PCDATA)>
   <!ELEMENT y (#PCDATA)>
   <!ELEMENT z (#PCDATA)>
   <!ELEMENT hardware (gps?, dgps?)>
   <!ELEMENT gps (#PCDATA)>
   <!ELEMENT dgps (#PCDATA)>


Appendix A.2

   XML Schema for a set of location elements of an imaginary car
   application.

   <?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema targetNamespace="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/car" xmlns:this="http://www-nrc.nokia.com/ietf-
   spatial/2001/05/08/car" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <xsd:element name="car-data" type="this:CarData"/>
   <xsd:complexType name="CarData">
       <xsd:sequence>
         <xsd:element name="car_orientation"
   type="this:OrientationType"/>
         <xsd:element name="hardware" type="this:HardwareType"
   minOccurs="0"/>
       </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="OrientationType">
       <xsd:sequence>
         <xsd:element name="x" type="xsd:decimal"/>
         <xsd:element name="y" type="xsd:decimal"/>
         <xsd:element name="z" type="xsd:decimal"/>
       </xsd:sequence>
     </xsd:complexType>
     <xsd:complexType name="HardwareType">
       <xsd:sequence>
         <xsd:element name="gps" type="xsd:string" minOccurs="0"/>

M. Korkea-aho, H. Tang                                         [Page 7]


Internet Draft             Spatial Location Payload            May 2001


         <xsd:element name="dgps" type="xsd:string" minOccurs="0"/>
       </xsd:sequence>
     </xsd:complexType>
   </xsd:schema>


Copyright Statement

Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English. The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."






















M. Korkea-aho, H. Tang                                         [Page 8]