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

[Tim Benson]

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 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.
>>