[New-ITS] Compactness of style (was: RE: Element content vs attributes)

Fri Jul 21 13:21:42 BST 2006

that's right, the ruids are just token replacements for
oids, so oids are still there in the background.

I'm a little pessimistic that we can remove the codeSystem
from the instance. The reason is the difference between
valueSet and codeSystem - is there good machinery to infer
that valueSet X with CWE means that the implementable model
can regard the codeSystem as fixed?

Grahame

Smithies Rik wrote:
> Hi Tim, Grahame
> 
> 
>> Can we can do what we want without using OIDs?
>>
>> If OIDs did not already exist today, is there is a real user 
>> requirement to invent them?  
>>
>> I think that the answers to the last 2 questions are probably 
>> YES and NO respectively 
> 
> I would have suggested NO and YES, so what are the alternatives ? You
> seem to need a namespacing method for codes and ids, hierarchical
> ideally, to ease sub-allocation, so OIDs work pretty well imho. They are
> verbose unfortunately. They also don't cover the requirement to say what
> type of ID something is.
> 
> UUIDs are also very verbose. You could certainly shrink messages a few
> percent by using a more compressed UUID format (eg base 36). They stick
> out like a sore thumb in flattened versions of current ITS examples. I
> once looked for an alternative and nothing came up. 
> 
> I like the idea of RUIDs, which I have also never seen before. But if in
> a given model a certain attribute is always, say, SCT, then there is no
> theoretical need to send the codeSystem all, hence no great advantage in
> shortening it. 
> 
> There is also the CodeSystemName if you want readability. The casual
> reader of XML will just see it's a code and read the displayName. It
> don't believe it help readability to the non-expert to have the OID
> shown in "english" as an RUID, it would be best to just have code and
> text. 
> 
> If the OID must be carried for some other reason, then if the RUID is
> shorter so much the better, but two formats are harder to support than
> one and OIDs aren't likely to disappear totally.
> 
> Rik
> 
>> -----Original Message-----
>> From: new-its-bounces at lists.hl7.org.uk 
>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson
>> Sent: 20 July 2006 12:49
>> To: grahame at jivamedical.com; ann.wrightson at bt.com
>> Cc: new-its at lists.hl7.org.uk
>> Subject: Re: [New-ITS] Compactness of style (was: RE: Element 
>> content vs attributes)
>>
>> The question is whether getting rid of OIDs would be 
>> friendly?  This raises several related questions.
>>
>> Are people so familiar with oids that they would miss them? 
>> In teaching HL7 I have not met anyone who was familiar with 
>> OIDs outside of HL7.
>>
>> Can we can do what we want without using OIDs?
>>
>> If OIDs did not already exist today, is there is a real user 
>> requirement to invent them?  
>>
>> I think that the answers to the last 2 questions are probably 
>> YES and NO respectively
>>
>> Tim
>>
>> On 20/7/06 10:27 Grahame Grieve wrote:
>>
>>> I will respond to this several times in different ways. One of the 
>>> things that this makes think is that we should dust off 
>> RUIDs. The HL7 
>>> type UID is either UUID, OID, or RUID. We've never defined 
>> any RUIDs, 
>>> so no one really talks about them. But we (HL7) could - we could 
>>> define
>>>
>>> snomed-CT = [some long oid]
>>> loinc = (some long oid)
>>> [all HL7 codesets names] = (hl7 oids)
>>> other common candidates as required
>>>
>>> then you could have <code codeSystem="snomed-CT" code="23123".../>
>>>
>>> (This doesn't address the xml issues - I Will take them up 
>>> separately.)
>>>
>>> But is this change something that would make the messages 
>> more friendly?
>>> Actually, it's possible that the UK realm could just define these 
>>> without lengthy consultation with HL7 under realm localisation. The 
>>> comments in the abstract data types say:
>>>
>>>   "A globally unique string defined exclusively by HL7. 
>> Identifiers in
>>>    this scheme are only defined by balloted HL7 
>> specifications. Local
>>>    communities or systems must never use such reserved identifiers
>>>    based on bilateral negotiations"
>>>
>>> ambiguous where a realm sits here. We could seek clarification. But 
>>> this is only worthwhile if getting rid of the oids would be 
>> friendly.
>>> comments?
>>>
>>> Grahame
>>>
>>>
>>> ann.wrightson at bt.com wrote:
>>>> A fork on the previous discussion:
>>>>
>>>> GG> I am left with a simple view: attributes are better cause they 
>>>> GG> use
>>>> less space, so use them when you can.
>>>>
>>>> If you package a non-XML data structure into XML in two 
>> ways, first 
>>>> using a general rule of 
>> put-data-attributes-into-XML-attributes, then 
>>>> using a general rule of 
>> put-data-attributes-into-XML-child-elements,
>>>> then yes XML attributes do use less space.
>>>>
>>>> However, if you allow translations that are more intelligent with 
>>>> respect to the nature of XML (for example, removing the constraint 
>>>> that all names and values in the abstractly-modelled non-XML data 
>>>> have to appear unchanged in the XML, including a short readable 
>>>> code-system-name in the implementable model, and thus 
>> allowing an OID 
>>>> to yield a readable tagname), an element-based style is able to be 
>>>> both readable and compact
>>>> - and could still be generated from the non-XML model. Such 
>>>> intelligence does have some cost; I would justify that by 
>> saying it's 
>>>> for the same reason as terminologies don't just use code-numbers - 
>>>> people, developers no less than clinicians, need clear-text 
>>>> linguistic forms of reasonable reliability and not just 
>> formally-unambiguous gobbledegook.
>>>> For example (from MIM 4.1.02):
>>>>
>>>> <code codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="371534008"
>>>> displayName="summary report" />
>>>>
>>>> can become:
>>>>
>>>> <SnCT code="371534008">summary report</SnCT>
>>>>
>>>> without the total loss of signal in the XML regarding the 
>> terminology 
>>>> being used that happens if you instead go to this kind of 
>> style (MIM
>>>> 4.1.03):
>>>>
>>>> <code code="163171000000105" displayName="Care Professional 
>>>> Documentation" />
>>>>
>>>> The "loss of signal" for implementers has emerged as the main 
>>>> practical issue here, IMO. However, assuming that all the names 
>>>> involved are about the same length, there is also some 
>> difference in 
>>>> the right direction in overall length. At its simplest this is eg:
>>>>
>>>> <aaaa bbbb="zzzz" cccc="xxxx" dddd="yyyy" />
>>>>
>>>> becoming:
>>>>
>>>> <zzzz dddd="yyyy" >xxxx</zzzz>
>>>>
>>>> The second also shortens by one step the XPath required to select 
>>>> this specific kind of element (and may reduce the size of an 
>>>> intermediate nodeset considerably). Of course, that also means it 
>>>> lengthens the XPath required to find all the XML elements 
>>>> corresponding to type "aaaa" in the underlying model... So 
>> as usual 
>>>> we are in a trade-off & need to judge which weighs heavier 
>> for our "market".
>>>> Ann W.
>>>>
>>
>> _______________________________________________
>> New-ITS mailing list
>> New-ITS at lists.hl7.org.uk
>> http://lists.hl7.org.uk/mailman/listinfo/new-its
>>
> 
> This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation.
> 
> 
> 

-- 
Grahame Grieve
CTO, Jiva Medical       Software Integration Tools
CTO, Kestral Computing  Healthcare Applications