Hi Pablo,
in openEHR, a terminology id of 'local' normally refers to terms inside
an archetype; each archetype is its own terminology. This makes sense
for clinical terms in an archetype, but not, I don't think, for terms to
do with data formats. We can easily add these to the openEHR vocabul
ine our own openEHR types without the need of registering those at IANA,
like ADL or OPT (e.g. text/opt+xml).
--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
Subject: Re: Term set for DV_PARSABLE.formalism
To: openehr-technical@lists.openehr.org
From: thomas.be...@oceaninformat
On 28/07/2015 18:49, pablo pazos wrote:
If that's the case, we lose the coding system / terminology of the
mime types that are defined.
It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE
instead of String and use "local" for the terminology_id of those
formalisms that doesn'
thoughtS?
--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
Date: Mon, 27 Jul 2015 08:23:49 +0200
Subject: Re: Term set for DV_PARSABLE.formalism
From: yamp...@gmail.com
To: openehr-technical@lists.openehr.org
CC: openehr-implement...@lists.openehr.org
Probably was left this way t
Probably was left this way to deal with the ones that don't have an
official mime, like adl
El 27/7/2015 7:11, "pablo pazos" escribió:
> Reading the specs I realize that there isn't a term set for
> DV_PARSABLE.formalism and it is a free text attribute.
>
> Sinc
Reading the specs I realize that there isn't a term set for
DV_PARSABLE.formalism and it is a free text attribute.
Since stuff like XML, JSON, CSV, etc. are in fact modeled by DV_PARSABLE, and
those have a MIME type associated (text/xml, application/json, text/csv, ...),
shouldn't w
6 matches
Mail list logo