Note that in AOM 1.5 (to be renamed AOM2) spec <http://www.openehr.org/releases/trunk/architecture/am/aom1.5.pdf>, the idea of fixed string 'ids' is gone. Multi-part ids are now generated functionally. See Fig 8
Right now, the functions interface_id and physical_id are defined a certain way, and they do include the 'v'. But other functions can be added. The only place I can think of where the full string id really matters is in ADL syntax. In all other syntax, it's in pieces. E.g. this is the JSON output from the current AWB for a flat archetype serialisation: I don't personally think it matters about having the 'v'. Although I fully agree that the anglo-centric nature of the internet (domain names, etc et) and IT in general (UML models are mostly published only in latin alphabet languages, and mostly english in multi-national orgs and standards orgs) is in one sense unfair, it's also a) there and b) useful in solving what could otherwise be protracted and useless debates on minutiae. The main reason to keep it is for backward compatibility in ADL texts; we could certainly define an 'id' function without it. - thomas On 03/10/2014 09:15, Bert Verhees wrote: > On 03-10-14 01:36, Bert Verhees wrote: >> org.openehr:openehr-ehr-composition.something:1.0.0 > > It seems wise to me to not regard the version-indication as a part of > the archetypeId, the same for the namespace. > > The archetypeId is to indicate what the conceptual contents of the > archetype is about. > The version does not changes this, so it should not be part of the > archetypeId, the same for the namespace. > > This idea justifies the use of the colon between namespace and > archetypeId and between version and archetypeId. > It also makes the use of the "v" before the version unnecessary. > > "V" is a language-specific indication, "v" stands for "version", and > "version" is an English/Latin term. > In Danish they say "udgave", in Russian it is "??????", in Hebrew: > "????", in Arabic: "????", in Maori: "putanga" and in Chinese: "??" > > Wonderful tool, Google translate ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: aehahefi.png Type: image/png Size: 40191 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0002.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: ehigebbb.png Type: image/png Size: 18564 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0003.png>
