Thank you for your comments. Ahead of more a thoughtful response, my apologies to James above all - for depicting him with said association - rather, I'm afraid it is my only a mistake in editing on my part.
-roger.
----- Original Message -----
From: Thomson, Martin [mailto:Martin.Thomson@commscope.com]
Sent: Wednesday, March 16, 2011 08:30 PM
To: geopriv@ietf.org <geopriv@ietf.org>; draft-marshall-geopriv-location-transform@tools.ietf.org <draft-marshall-geopriv-location-transform@tools.ietf.org>
Subject: draft-marshall-geopriv-location-transform-00
This new attempt on the old idea is a good sign that the authors are intent on getting this right. I like that.
At this stage, there isn't a really enough detail to properly assess the draft.
I think that the basic model that is hinted at in Section 8 could be structured differently. The current suggestion has several points of articulation. Civic has a range of profiles, which is probably only one layer; but geodetic locations have both CRS and shape. That leads to a plethora of transformations when all combinations are considered.
When each is combined, both input and output of the transformation need to be described with a subset of: location type, civic address profile, civic address language, geographic CRS, geodetic shape, and anything else that is later added.
Rather than specify a whole range of x-to-y transforms, in all the combinatorial glory that implies, this could be made quite simple. The service accepts a location and a description of the location that is desired. The service either produces the desired form, or an error. The error can indicate that the target form is not supported, or that the input form is not one of those that are supported for the output form (or the range of other errors specific to the transformation). In either case, the service might be able to describe the forms that it desires.
That all assumes that you are using a request-response model for the protocol, which would seem to be the case, but that detail is absent. I can think of other models, some of which could have advantages. For instance, if you could imagine using REST and even HTTP content negotiation for the transformed object, it might work, particularly when you are talking about producing civic addresses, which might be manifested as discrete resources.
--Martin
p.s. I was surprised to see that James is now working for TCS..., or not.
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
