Tim, As I mentioned, the requirement was to have a hash that can be referenced at runtime without the need to reference an online service. For example a recent version of the Ocean Template Designer includes integrity checking of archetypes used in a template to ensure that the archetype is the same as the one used when the template was last saved. If this process needed to perform these hash lookups using an online service there would be significant impact on the user experience. The latest version of the Ocean Archetype Editor provides this hash in the description other_details so that it can be easily ignored by systems that don't utilise it.
The other point you make about the hash being provided by CKM is also worth commenting on. A simple hash on the ADL was not considered useful for the process above. For one, the hash of the archetype would be different for ADL and XML files. Secondly, any insignificant change (comments, whitespace, description meta-data) to the ADL file will change the hash even though the content (Archetype) model has not. For this reason we developed a canonical archetype serialization algorithm ensuring that the hash would be constant as long as the content model was the same. Unfortunately, this algorithm did include the ontology and its translations but this was deemed to be a change to the content model, hence a new hash value was necessary. I will contribute this canonical archetype serialization and hashing specification to the openEHR wiki as soon as I can get Thomas to create me a page. Regards Heath > -----Original Message----- > From: Tim Cook [mailto:timothywayne.cook at gmail.com] > Sent: Thursday, 30 April 2009 7:08 PM > To: Heath Frankel > Cc: 'For openEHR technical discussions' > Subject: RE: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in > the ADL are not efficient and should instead use 'gettext' catalogs.] > > On Thu, 2009-04-30 at 16:28 +0930, Heath Frankel wrote: > > Hi Koray, > > > > I will let others respond about translations etc, but I did want to > > pick up on your point about multi-part file. This was an option > > recently consider when we were looking at a mechanism to record an > MD5 > > Hash of the archetype. There was a desire to provide this hash > > external to the ADL itself whilst making it available to the > archetype > > consumer locally so it was not necessary to query some external > notary > > service to do the integrity check. Using a multi-part file would > > allow the usual PGP message and signature parts to be used. It was > > thought to be quite a disruptive change, but if there are other > > reasons to do this... > > The MD5 for an archetype is now available in the CKM. IIRC, this was > to verify the validity of the actual ADL source aas having come from > the CKM. > > But, since archetype exports are being generated as .zip files there is > no reason (that I can think of) why this couldn't be applied on the fly > if a user selects only a few languages (as Hugh suggested) or if a > bundle is created that includes the original language plus specific .po > translation files. > > As I said in my response to Hugh, this is certainly a long term issue > but I think it should be addressed sooner rather than later. > > Cheers, > Tim >
