LQS: parsing of QualifiedNameStrs

• Key: LQS11-1
• Legacy Issue Number: 7597
• Status: open  
• Source: Foundation for Research and Technology ( Stelios Sfakianakis)
• Summary:

  According to the LQS specification (00-06-31), paragraph 2.1.4, the
  delimiter between a NamingEntity (NE) and a LocalName (LN) is the
  character '/', possibly excluding only the case of the 'OTHER'
  RegistrationAuthority.

  Reading this paragraph it is clear to me that in order to parse a
  QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's
  not 'IDL' or 'OTHER'), the first '/' is the delimiter between a NE
  and a LN, which also means that, in these cases, a '/' is not
  permitted inside a NE. If a QualifiedNameStr starts with "IDL" then
  the delimiter is the last occurence of '/'.

  The problem is that subsequent paragraphs in the specification (and
  also coding schemes and codes defined in the idls of LQS) DO NOT use
  these rules. For example the ICD-9-CM coding scheme should be
  represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which
  clearly is illegal because it uses the slash character inside the NE
  (which is the "hl7.omg.org/I9C"). There are numerous such cases
  throughout the spec.

  It is clear that if this kind of QualifiedNameStrs is acceptable then
  it is not feasible to have a "generic" implementation of the
  translation_library's str_to_qualified_code method: If I have a PIDS
  that supports a trait to represent the patient's spoken language and
  as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6)
  then according to 2.1.4 I should search LQS for the coding scheme
  "DNS:usmarc.omg.org" but I would probably find nothing because the
  ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus
  I should be aware that when I see such codes, the coding scheme is the
  "DNS:usmarc.omg.org/041" and the rest is the concept code. But this
  forces me, as implementer of the translation library, to know all the
  possible coding schemes in order to parse them correctly.

  So my questions are:

  • Are the remarks mentioned above correct and well known?

  • If yes how the OMG is going to tackle this issue?

  • If the OMG considers it too costly to change all the examples in
    the spec. and the stringified coding schemes in the idls, what is
    the proposed way to implement the translation_library interface?
    (One solution might be to have the LQS expose a translation_library
    interface through the TerminologyService interface and let the LQS
    server do the "correct" transformation ...)

  [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it
  refers to "UniqueName" and "UniqueNameStr" which are unknown and it
  possibly means QualifiedName and QualifiedNameStr
  respectively. Secondly, it says that the character ':' should be the
  delimiter between NE and LN (!!).]

• Reported: LQS 1.1 — Thu, 22 Jul 2004 04:00 GMT
• Updated: Fri, 6 Mar 2015 20:58 GMT