This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Datatypes R2 Issue 3"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 99: Line 99:
  
 
== Disposition ==
 
== Disposition ==
 +
 +
INM, 2 May 2007:
 +
 +
There is another way to solve this problem: make the attribute type SET<ED> instead of
 +
ED. This allows committees to more precisely specify how the translations are done, but
 +
does require more committee work.
 +
 +
Straw vote on 3 options:
 +
# accept as proposed 1
 +
# Change RIM ED type attributes to SET<ED> 1
 +
# Nothing is required - attach multiple documents (maybe necessary to check that model allows for this?) 4
 +
# abstain 4
 +
 +
Further discussion with Lloyd to follow
 +
 +
Attaching multiple documents is problematic because you don't want to repeat any of the discrete elements and I've only got one object.  For example, if I have a prescription and I send a rendered human-readable version of the prescription in the root SubstanceAdministration.text, I may need to send multiple rendered versions.  I can't have two copies of the prescription because it's only one order and one authorized quantity.  You can't suspend the English rendering and not the French rendering.  Even within the same message, I don't want to duplicate all of the structured content.  Changing to SET<ED> could work if that were the preference.  --[[User:Lmckenzi|Lmckenzi]] 01:23, 3 May 2007 (CDT)
 +
 +
Another option: a translation association. This allows specification of more information.
 +
 +
Lloyd: While a translation association is more powerful, it requires significant modeling changes all over the place.  Every single string or ED you want to provide a translation for necessitates a separate translation association.  It's also not clear how you'd manage identifying which attribute you're translating in situations where a class has multiple attributes or multiple repetitions of an attribute.
 +
 +
Fundamentally, I'm not sure what the pushback is.  Translation is specific to the attribute (or property).  I'm happy to have flavors of ED, ST, etc. that prevent translations that can be used in those places where translation is inappropriate.  What is the concern with introducing it?--[[User:Lmckenzi|Lmckenzi]] 11:50, 16 May 2007 (CDT)
  
 
== Status ==
 
== Status ==
  
Proposed
+
INM call Mon Jun 18 2007: Add this with a note about it's status, and see what happens at ballot
  
 
== Links ==
 
== Links ==
 
Back to [[Data Types R2 issues]]
 
Back to [[Data Types R2 issues]]

Latest revision as of 11:31, 20 June 2007

Data Types Issue 3: Add ED.translation

Introduction

Add support for conveying multiple language or format translations of equivalent content within the ED type. There are situations in several international affiliates where they need to be able to convey the same information in multiple languages. Repeating the entire message content for each translation represents an unnecessary and unreasonable burden.

Is backward compatible.

HL7 Canada

Discussion

Table 5: Property Summary of Encapsulated Data Name Type Description translation SET<ED> Identifies the type of the encapsulated data and identifies a method to interpret or render the data.

Definition 40: type EncapsulatedData alias ED specializes BIN {

 CS   mediaType;
 CS   charset;
 CS   language;
 CS   compression;
 TEL  reference;
 BIN  integrityCheck;
 CS   integrityCheckAlgorithm;
 ED   thumbnail;
 SET<ED> translation;
 BL   equal(ANY x);

};

Properties of Encapsulated Data (ED) Translation (translation : SET<ED>)

Definition: Identifies alternate renditions of the same content translated into a different language. The translation property is a set of encapsulated data that each translate the first rendition into different language. Each element of the translation set was translated from the first encapsulated data. Each translation may, however, also contain translations. Thus, when a document or string is translated multiple times the information about which rendition served as the input to which translation will be preserved. Note: This property should not be used to communicate different transformations or renderings of a set of content. For example, a CDA document would not be a translation of a free-text report. <We could add an invariant requiring that the language in a translation be different than the original, but I’m not sure it’s necessary. There may even be use-cases where translations to the same language is useful. E.g. simplifying terminology.>

<x

 nullFlavor = {nullFlavor}                    
 representation = "B64"|"TXT"       
 language = {language}
 charset = {charset}
 mediaType = {mediaType}
 compression = {compression}
 integrityCheck = {IntegrityCheck}
 integrityCheckAlgorithm = {IntegrityCheckAlgorithm}
 >
 -->
   translation : SET<ED>

</x>

Schema Fragment 12:

<xsd:complexTypename="ED" mixed="true">

   <xsd:complexContent>
       <xsd:extensionbase="BIN">
           <xsd:sequence>
               <xsd:elementname="reference" type="TEL" ... />
               <xsd:elementname="thumbnail" ... />
               <xsd:elementname="translation" ... />
           </xsd:sequence>
           <xsd:attributename="mediaType" type="cs" ... />
           <xsd:attributename="language" type="cs" ... />
           <xsd:attributename="compression" type="cs_CompressionAlgorithm" ... />
           <xsd:attributename="integrityCheck" type="bin" ... />
           <xsd:attributename="integrityCheckAlgorithm" type="cs_IntegrityCheckAlgorithm" ... />
       </xsd:extension>
   </xsd:complexContent>

</xsd:complexType>

<xsd:elementname="translation" minOccurs="0" maxOccurs="unbounded">

   <gsd:templatename="SET" as="type">
       <gsd:withParamname="T" type="ED" />
   </gsd:template>

</xsd:element>


Paul Biron: Is there a constraint that translation only be used when the mime-type is text/plain (or other textual types)? That is, what if the original ED.mediaType was image/jpeg...does it make sense to include a translation in that case? Just wondering...

Lloyd: In theory you could have a movie dubbed in French or Japanese . . . I expect it would mostly be used for text, but semantically it would make sense any place language does (and language isn't restricted to text only).

Paul: OK, I guess I see your point...and I also guess that it's not necessary to put a contraint that the mime type of the orig and the xlation need to be same, e.g., if the orig is a movie in french the translation could be text in english. Is that your intention?

Lloyd: OK, I guess I see your point...and I also guess that it's not necessary to put a contraint that the mime type of the orig and the xlation need to be same, e.g., if the orig is a movie in french the translation could be text in english. Is that your intention?


Disposition

INM, 2 May 2007:

There is another way to solve this problem: make the attribute type SET<ED> instead of ED. This allows committees to more precisely specify how the translations are done, but does require more committee work.

Straw vote on 3 options:

  1. accept as proposed 1
  2. Change RIM ED type attributes to SET<ED> 1
  3. Nothing is required - attach multiple documents (maybe necessary to check that model allows for this?) 4
  4. abstain 4

Further discussion with Lloyd to follow

Attaching multiple documents is problematic because you don't want to repeat any of the discrete elements and I've only got one object. For example, if I have a prescription and I send a rendered human-readable version of the prescription in the root SubstanceAdministration.text, I may need to send multiple rendered versions. I can't have two copies of the prescription because it's only one order and one authorized quantity. You can't suspend the English rendering and not the French rendering. Even within the same message, I don't want to duplicate all of the structured content. Changing to SET<ED> could work if that were the preference. --Lmckenzi 01:23, 3 May 2007 (CDT)

Another option: a translation association. This allows specification of more information.

Lloyd: While a translation association is more powerful, it requires significant modeling changes all over the place. Every single string or ED you want to provide a translation for necessitates a separate translation association. It's also not clear how you'd manage identifying which attribute you're translating in situations where a class has multiple attributes or multiple repetitions of an attribute.

Fundamentally, I'm not sure what the pushback is. Translation is specific to the attribute (or property). I'm happy to have flavors of ED, ST, etc. that prevent translations that can be used in those places where translation is inappropriate. What is the concern with introducing it?--Lmckenzi 11:50, 16 May 2007 (CDT)

Status

INM call Mon Jun 18 2007: Add this with a note about it's status, and see what happens at ballot

Links

Back to Data Types R2 issues