Open howardtrickey opened 4 months ago
Need to enquire whether this issue has been discussed and/or addressed by INSPIRE
string identifiers in a POI represented as Internationalised text (i.e. multiple instances of the text object per language)
Check with Bart and Carl Reed.
I've lately been looking at Apple's IMDF (indoor mapping format), which has addressed some of the issues we have been dealing with, but only from the point of a JSON encoding, where they have reached approximately the same solution as we had discussed early (language tags): see https://register.apple.com/resources/imdf/reference/type_designators#labels
It is also instructive to look at what they've done for categories https://register.apple.com/resources/imdf/reference/categories#occupant , hours https://register.apple.com/resources/imdf/reference/type_designators#hours , and POIs in general (which they call "occupant") https://register.apple.com/resources/imdf/types/occupant
Please review and comment on the Internationalized Text white paper. This white paper will be submitted to the OAB to inform their discussion on internationalized text. However, it is still a bit rough.
In trying to redo the Best Practices Guide to use our latest decision on how to handle internationalized strings, I find I need help in identifying the relevant standards.
We have decided that we simply need say that: everywhere there is a CharacterString used, its multiplicity should be allowed to be greater than 1, and that the implementation technology (JSON, XML, etc.) will have its own mechanisms for tagging / annotating those strings with a language identifier.
I have two questions:
In XML, it appears the that the standard-defined way of doing this is to use an xml:lang= field on an xml element that we wish to so identify. I suppose this means that any CharacterString type equivalent in XML needs a element to enclose it, right? I guess this is OK but just wanted to check.
I am not able to find a standard-specified way to do this in JSON. Does someone have a reference to such a thing? If not, does that mean we have to specify in our JSON implementation spec for our standard how to do such identification? What would we be thinking of? Perhaps a structure like: { string = "some string", lang = "en" }
?