One of the assumptions is that things are commonly labeled, but that's rather rare in practice. Naming is typically implicit and by context, i.e., your hotel room doesn't have a label "Room 742", but rather just a carved label with the digits 7-4-2 on it. The same is generally true for airport gates, airport terminals and a whole bunch of other sub-building labels. Naturally, the building model may have some set of labels, but they are not visible to visitors and other consumers of location information.
Thus, if you want to support I18N, you want to have as many generally-understood labels, so that my German indoor location client can render "(Room) 742" as "Zimmer 742". More dramatically, in a Chinese hotel, that rendering is much more meaningful to the non-Chinese visitor than the Chinese symbol for room, which is likely nowhere to be seen on a wall or door sign. The Chinese LIS likely won't know German, even if it could do some translation (which is unlikely, given the multiple delivery steps between the source of location and the final consumer).
It is clear that there are less-common sub-building units where we simply can't define CA types or XML tags for all of them. For those, I have no objection to use the IN tag. However, for the very common ones (the current ones), the current explicit labels provide a much better user experience as long as they indeed map to their real meaning. In other words, it's a bad idea to label an airport "gate" as a "room".
Thus, the combination of using FLR etc. for the 80% of common buildings (office, hotels, residences), while dealing with the special cases with IN labels seems to give the best compromise between semantic tagging and flexibility to deal with the other 20%.
Otherwise, you'll have to define a registry of well-known IN XML attributes. In that model, the Chinese hotel would have to use the English literal "Room" for the IN label, even though it uses Chinese-language labels for all the other attributes.
Henning
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
