Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in aPIDF-LO

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 1 Aug 2008 04:59:27 -0500

Ted, I was going to say the same thing about readability.  Perhaps I'm not sufficiently JSON-literate to be able to do that.

JSON can, in many respects, be considered as a competitor to XML.  We could equally use protocol buffers (c.f. google code).  Or, given that we have already made the choice for XML, we could recognise that one format is preferable over many.  XML compactness can be achieved through compression, or through other encodings of the infoset, like X.694.

Cheers,
Martin

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, 1 August 2008 9:57 AM
> To: Carl Reed; Winterbottom, James; James M. Polk; Thomson, Martin;
> Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in
> aPIDF-LO
> 
> At 2:46 PM -0700 7/31/08, Carl Reed wrote:
> >Not to muddy the water on this topic, but if there is ever a need for
> a more compact LO in addition to the current LO, consider GeoJSON
> approach which is modelled on GeoRSS GML. Very compact and still human
> readable.
> >
> 
> While I would be happy to agree to "compact", I think your value of
> human readable
> is for some value of human that wouldn't include most of the planet.
> As a rule of
> thumb, anything that involves floating point numbers and mixed/nested
> brackets and braces is not really human readable.  Can we maybe agree
> on "textual" :) ?
> 
> The key thing that makes an LO in geopriv, though, is the policy
> association
> with the location.  If we wish to make a compact LO based on GeoJSON,
> we'd need to find some equally compact way of expressing the policies.
> 
> regards,
> 
> Ted
> 
> >A GeoJSON polygon coding looks like:
> >
> > {"type":"Feature", "id":"OpenLayers.Feature.Vector_124",
> "properties":{}, "geometry":{"type":"Polygon", "coordinates":[[[-
> 1.40625, 24.2578125], [-4.21875, 7.3828125], [42.890625, 3.8671875],
> [29.53125, 29.1796875], [10.546875, 25.6640625], [-1.40625,
> 24.2578125]]]}, "crs":{"type":"OGC",
> "properties":{"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}}}
> >
> >As one of the original GeoRSS authors, I am a bit biased :-)
> >
> >Carl
> >
> >----- Original Message -----
> >From: "Winterbottom, James"
> <<mailto:[email-masked]>[email-masked]>
> >To: "James M. Polk" <<mailto:[email-masked]>[email-masked]>;
> "Thomson, Martin"
> <<mailto:[email-masked]>[email-masked]>; "Hannes
> Tschofenig"
> <<mailto:[email-masked]>[email-masked]>
> >Cc: <<mailto:[email-masked]>[email-masked]>
> >Sent: Thursday, July 31, 2008 3:24 PM
> >Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location
> in aPIDF-LO
> >
> > >
> >> Hi James,
> >>
> >> The big PIDF-LO horse has long since bolted from the stables.
> >> If you are looking for a lean and slick way to represent location
> for specific functions, such as routing, then we need to totally re-
> think our representation and perhaps look at binary forms.
> >>
> >> I think that it is too late to argue that PIDF-LO is too big.
> >>
> >> Cheers
> >> James
> >>
> >> -----Original Message-----
> >> From: James M. Polk [mailto:[email-masked]]
> >> Sent: Thu 7/31/2008 2:46 AM
> >> To: Winterbottom, James; Thomson, Martin; Hannes Tschofenig
> >> Cc: <mailto:[email-masked]>[email-masked]
> >> Subject: Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location
> in  a PIDF-LO
> >>
> >> At 04:44 PM 7/30/2008, Winterbottom, James wrote:
> >>>Hi James,
> >>>
> >>>"how about just having a URI (to be dereferenced) as the only
> >>><derived-from> element value?
> >>>
> >>>I keep seeing a separate <location-info> element with a full
> location
> >>>as the derived location. This is the waste, and expensive, bandwidth
> >>>hog that should be avoided."
> >>>
> >>>[AJW] The only reason you keep seeing this is because you haven't
> >>>read the draft:
> >>>The abstract says "The source
> >>>    location may reside in the same PIDF-LO or be a remote document
> >>>    referenced by a location URI and associated id fragement."
> >>
> >> I'm saying it shouldn't be possible to have this long, protracted
> >> dual <location-info> element in the first place.
> >>
> >>
> >>>Section 4 on page 7 is titled "Linking to External Locations"
> >>>With figure 2 showing how this is done.
> >>
> >> this should be your proposal
> >>
> >>
> >>>And to cap it off I sent an email to the list yesterday asking how
> >>>figure 2 supposedly doubled the size the PIDF-LO.
> >>>http://www.ietf.org/mail-archive/web/geopriv/current/msg06141.html
> >>
> >> great -- but some of us are occasionally busy enough that we don't
> >> get to our email within 1 day's time, so stop berating me for not
> >> immediately having read and understood and agreed with your note....
> > >
> >> jeez, dude, lighten up
> >>
> >>
> >>>The concept of this is a trivial thing and really doesn't warrant a
> >>>complete requirements document for it.
> >>
> >> that, I believe, is your opinion -- which occurs towards your work.
> >>
> >>>If you want more information in the document about taking care not
> >>>to over inflate the PIDF-LO when SIP is being used over UDP, we can
> do that.
> >>
> >> ignorance of the constraints of other protocols is an interesting
> >> plea, especially when we've talked about this topic before --
> >> including face2face.
> >>
> >>>I have received some other very good feed back from others also that
> >>>I will include in the next rev.
> >>>
> >>>Cheers
> >>>James
> >>>
> >>>
> >>>
> >>>
> >>>--------------------------------------------------------------------
> ----------------------------
> >>>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
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> ----------------------------
> >> 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
> >> <mailto:[email-masked]>[email-masked]
> >>
> <https://www.ietf.org/mailman/listinfo/geopriv>https://www.ietf.org/mai
> lman/listinfo/geopriv
> >
> >Content-Type: text/plain; name="ATT00001.txt"
> >Content-Description: ATT00001.txt
> >Content-Disposition: attachment; filename="ATT00001.txt"; size=200;
> >	creation-date="Thu, 31 Jul 2008 15:12:56 GMT";
> >	modification-date="Thu, 31 Jul 2008 15:12:56 GMT"
> >
> >Attachment converted: Macintosh HD:ATT00001 3594.txt (TEXT/ttxt)
> (0081526B)
> 

------------------------------------------------------------------------------------------------
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: [email-masked]
Date: Fri, 1 Aug 2008 10:22:56 -0400 (EDT)

Perhaps I "hang" out too much with the geospatial open source community -
they are big on "human readable". Perhaps they should really say
"programmer readable" :-)

Regards

Carl
>>Not to muddy the water on this topic, but if there is ever a need for a
>> more compact LO in addition to the current LO, consider GeoJSON approach
>> which is modelled on GeoRSS GML. Very compact and still human readable.
>>
>
> While I would be happy to agree to "compact", I think your value of human
> readable
> is for some value of human that wouldn't include most of the planet.  As a
> rule of
> brackets and braces is not really human readable.  Can we maybe agree on
> "textual" :) ?
>
>> "properties":{}, "geometry":{"type":"Polygon",
>> "coordinates":[[[-1.40625, 24.2578125], [-4.21875, 7.3828125],
>> [42.890625, 3.8671875], [29.53125, 29.1796875], [10.546875, 25.6640625],
>> [-1.40625, 24.2578125]]]}, "crs":{"type":"OGC",
>> Tschofenig" <<mailto:[email-masked]>[email-masked]>
>>> If you are looking for a lean and slick way to represent location for
>>> specific functions, such as routing, then we need to totally re-think
>>> our representation and perhaps look at binary forms.
>>>
>>>  a PIDF-LO
>>>>I keep seeing a separate <location-info> element with a full location
>>>>to over inflate the PIDF-LO when SIP is being used over UDP, we can do
>>>> that.
>>>
>>> <https://www.ietf.org/mailman/listinfo/geopriv>https://www.ietf.org/mailman/listinfo/geopriv
>>

---

From: [email-masked]
Date: Fri, 1 Aug 2008 10:28:26 -0400 (EDT)

Agreed -

As I said, I did not want to stir the waters.

Apologies for getting off track.

Carl

> Ted, I was going to say the same thing about readability.  Perhaps I'm not
> sufficiently JSON-literate to be able to do that.
>
> JSON can, in many respects, be considered as a competitor to XML.  We
> could equally use protocol buffers (c.f. google code).  Or, given that we
> have already made the choice for XML, we could recognise that one format
> is preferable over many.  XML compactness can be achieved through
> compression, or through other encodings of the infoset, like X.694.
>
> Cheers,
> Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 1 Aug 2008 09:46:36 -0500

I wouldn't want to discourage you from sharing the work that is going on in your organisation.  Far from it, we get so little sharing between SDOs that I find your input to be of genuine benefit.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, 1 August 2008 3:28 PM
> To: Thomson, Martin
> Cc: Ted Hardie; Carl Reed; Winterbottom, James; James M. Polk; Hannes
> Tschofenig; [email-masked]
> Subject: RE: [Geopriv] [Ecrit] Announce: Specifying Derived Location in
> aPIDF-LO
> 
> Agreed -
> 
> in
> >> >>>http://www.ietf.org/mail-
> archive/web/geopriv/current/msg06141.html
> >> >>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 1 Aug 2008 18:28:00 -0500

Also I think we would need to have a civic representation also, otherwise we would be deriving geo form geo, which doesn't seem terribly useful.

-----Original Message-----
From: Thomson, Martin
Sent: Fri 8/1/2008 4:59 AM
To: Ted Hardie; Carl Reed; Winterbottom, James; James M. Polk; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] [Ecrit] Announce: Specifying Derived Location in  aPIDF-LO

Cheers,
Martin