# Term set for DV\_PARSABLE.formalism
**URL:** https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377
**Category:** Implementers (archive)
**Created:** [27 July 2015 05:11 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377 "2015-07-27T05:11:06Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [27 July 2015 05:11 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/1 "2015-07-27T05:11:06Z")
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 we define a term set for that attribute like we have for DV\_MULTIMEDIA.media\_type? (of course this attribute is CODE\_PHRASE and not String like “formalism”).
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [27 July 2015 06:23 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/2 "2015-07-27T06:23:49Z")
Probably was left this way to deal with the ones that don’t have an official mime, like adl
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [28 July 2015 17:49 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/3 "2015-07-28T17:49:35Z")
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’t have a mime type.
thoughtS?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [28 July 2015 18:38 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/4 "2015-07-28T18:38:40Z")
well actually we could do that and put all those other formalisms into the openEHR terminology. The original idea was to allow (encourage) MIME types as strings, and then outside of MIME, any other formats just as their own short string, e.g. ‘mp5’ (imagine it exists), or ‘adl’. There are a lot of formats that are essentially text/plain, but the format is actually parseable, e.g. glif3, most programming languages and so on. So ‘text/plain’ isn’t that useful a thing to know. I wonder if we have to give in and have two fields, one that is a MIME type field (the current one) and a second field that has a term defining the semantic format, mostly applicable when the MIME type field is text/plain, text/xml and other text types. - thomas
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [29 July 2015 00:04 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/5 "2015-07-29T00:04:06Z")
I think we can put the formalisms we know in the terminology, but being flexible to allow local formalisms, like using “local” for the terminology\_id. If we don’t do that, we’ll need to maintain the terminology for every new formalism.
Not sure about having two fields, it seems the role of both is the same. We can do that with parameters or suffixes on MIME types (the structure allows that): [https://en.wikipedia.org/wiki/Internet\_media\_type](https://en.wikipedia.org/wiki/Internet_media_type)
With CODE\_PHRASE we can cover both cases, defined and non-defined MIME types.
If the MIME type is String, we lose control over the values, I’m considering trying to process something I receive and not “understanding” that String. With terminology = local, I know that I may not have the code (if “local” is another system), but for a MIME type from IANA I will have it. Also this allow us to define our own openEHR types without the need of registering those at IANA, like ADL or OPT (e.g. text/opt+xml).
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [29 July 2015 06:55 UTC](https://discourse.openehr.org/t/term-set-for-dv-parsable-formalism/15377/6 "2015-07-29T06:55:15Z")
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 vocabulary, then that provides a reliable single source of such terms, and doesn't require archetype authors to re-invent (different) terms for the same thing repeatedly.
- thomas