On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton <[email protected]> wrote: > > Some comments I have on 0255 during implementation: > > > - XEP-0080 uses <lat>, <lon>, <alt> instead of <latitude>, <longitude>... > so the examples need to be changed. The schema looks right though.
Have updated the examples. Thanks for reporting. Also I have added the optional element <signalstrength> to the <beacon> element, which is something I just plain forgot about in the earlier versions (@Peter: will send you updated xml file) > - Is Example 7 allowed in XMPP/pubsub? It looks like the component is > publishing to the entities node. I suppose there is nothing wrong with > that, I just haven't seen it before. I was wondering the same thing when i wrote the draft. It is probably not the intended use of pubsub, but it does save a round trip of the location results. In buddycloud we have configured our location component such that our server (ejabberd) allows it to post on behalf of users (@Simon: correct me if I'm wrong or unclear on this) Helge >> To: [email protected]> Date: Wed, 26 Nov 2008 22:43:45 +0100> From: > [email protected]> Subject: [Standards] XEP-0255 (Location Query)> > > > Some comments to the XEP-0255 / "Location Query" draft > (http://xmpp.org/extensions/xep-0255.html):> > 1) Beacon signal strength > seems to have been forgotten in the draft specification. This is a mistake > and I will correct it. > > 2) In the development project from which > XEP-0255 was born (Buddycloud), we never considered using Timing Advance > (http://en.wikipedia.org/wiki/Timing_advance) for triangulation between > cell towers, simply because it was too troublesome getting the deep API > access required on Symbian, our main client platform.> > However I assume > this is something other implementers may want to use, so i think it should > be covered by the XEP.> > The specification currently uses a generic data > type for all radio beacons (cell towers, wifi access points, bluetooth > devices). However timing advance would only apply to cell towers. In order > to keep this symmetry, and as timing advance translate directly to distance > (scaled by a factor of 550m per unit), i am pondering whether to add the > somewhat more generic field 'distance' rather than 'timing advance'. I am > not sure how a client would derive distance to, say a wifi access point, > but I think that is more likely than a timing advance value...> > Any > thoughts?> > > Helge> > _________________________________________________________________ > Send e-mail faster without improving your typing skills. > http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 >
