Andrew Newton wrote:
No! Client may not have the same location in civic and geo, the
location that these two profiles
may overlap but probably has different accuracy. My geo location that I
my GPS may be very accurate to a point and because of its accuracy would
be the preferred
On Feb 15, 2007, at 1:00 AM, Shida Schubert wrote:
So if support simply implies that server understands the profile
<notFound> is really
useless and some additional information should be provided to aid the
client in making
an intelligent decision.
If it can't return an error, some sort of warning that provides the
seeker with a hint
implying which profile is needed for the resolution may be desirable.
This implies that the client making the query in geo also has the same
location in civic and vice versa. That's a pretty big assumption. We
have discussed this issue in great detail on this list, and the
consensus was that if a client has location in both geo and civic and
wishes to get an answer for both, the client will simply make two
separate queries -- one for geo and one for civic. A <notFound> for
one query will not prevent it from getting the information for the other.
location to be used when my UA sends a LoST query.
According to your comment, there is a possibility that geo may not
resolve to any URI even
when recursive="true", because none of the authoritative servers
responsible for the region
may hold the resolution data for geo.
If I obtain an error <notFound> but I know from
<listServicesByRegionResponse> that resolution
for the service I want is provided, I may want to re-try query with
inaccurate civic location
information I obtain through DHCP.
If resolution for civic is available, at least I get some URI to
contact the service I am interested in,
accurate location information can be provided then.
* I really hope that for an emergency case(service:sos), there will be
a text in phone-bcp
mandating the administrator of LoST to maintain mapping data for both
geo/civic within the region
so client only supporting geo or vice versa will at least get some kind
of resolution. Furthermore,
to increase the chance of obtaining the mapping data, I would also
at all time.
One question was unanswered..
If resolution is provided only for non mandatory-to-implement profile,
would it still be listed
in the <listServicesResponse> as service supported? If so I do think
Although I am aware that it is out of scope of protocol definition, but if
there is no indication of which profile is supported(data
available)/service, some text imposing
/recommending the server to provide resolution in at least one of the
base profile should exist
for the protocol to be useful...
Further, it would be useful to have the ability to express the
"profile type supported"/service
in <listServiceResponse> as well as <listServiceByRegion>.
I'm indifferent to this idea. If others support it, we could add it in.
After I wrote this I looked at the schema and saw that defaultValue for
recursive is "true" but section 7.3.3 says it's default value is
"false". I am
a bit confused is the default "false" or "true"?
-- Text from section 7.3.3 --
"A value of "true" indicates a recursive query, with the default being
"false" when the attribute is omitted.
That'll have to get fixed. I'm inclined to have it default to true.
I am inclined to have it default to true as well.
Ecrit mailing list