DV_TEXT vs. DV_PARSABLE with formalism "text/plain"

Clinical (archive)
1

Hi,

I’m playing around with the AE and have a question about the semantics in the differences between specifying an ELEMENT.value as DV_TEXT or a DV_PARSABLE with formalism = “text/plain”.

Since text/plain MIME type is used for narrative text and DV_TEXT is just for that, why text/plain is allowed on the constraints for DV_PARSABLE.formalism?

Is there any use case specific for DV_PARSABLE text/plain that can’t be modeled as DV_TEXT?

Thanks!

2

A use case could be to specialize archetypes with DV_PARSABLE and constraint that to “text/plain” to mimic a DV_TEXT. Maybe there is a more obvious use case

3

So DV_TEXT and DV_PARSABLE text/plain are semantically the same thing?

4

well, you can provide more things to the DV_TEXT in that case, such as term mappings or specify an hyperlink

5

And you can use a dv_coded_text in place of a dv_text because of the inheritance.

But you can put newlines in a parsable with formalism text/plain and still adhere to the specification.

6

Thanks Diego and Pieter,

That is exactly what makes me think if formalism = text/plain should be allowed in DV_PARSABLE, since IMO to be “parsable” is to have some kind of structure, an structure plain text doesn’t have.

Currently the specs are not so specific on the DV_PARSABLE formalism, in fact current description is a little out of date “Name of the formalism, e.g. GLIF 1.0 , Proforma etc.”. https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class

Best,
Pablo.

7

Hi,

Although MIME types are very flexible, there is not a MIME for everything that exists. Doing some research, I’ve seen that text/plain is used for representing C, C++ or Java code. And it could be also used for any a proprietary syntax. So I think it is perfectly valid to have it in DV_PARSABLE.

8

This is a bit odd indeed in my understanding:

The formalism is not really well defined it seems – and can be anything.

If we assume for a moment (and AE seems to do so) that the formalism is expressed as a MIME type, text/plain makes sense for parsable text that doesn’t have a MIME type as such (such as ADL itself is parsable but doesn’t have a MIME type of its own as far as I know, and is not XML or similar either…).

However, I am not sure if a MIME type is sufficient here then – rather not.

A MIME type could be an extra more standardised - but often less specific - attribute in addition to the formalism.

(Alas, not sure how much value that would add.)

Text/plain is also a bit unfortunate because the description of DV_PARSABLE mentions that “the form of the data is assumed to be plaintext, rather than compressed or other types of large binary data.” (emphasis mine)

Regards,

Sebastian

9

@David, I think the DV_PARSABLE.formalism is not constrained only to MIME types, and has a broader set of possible values. I fact to store something that doesn’t have a MIME type but is “parsable”, should be specified by other value than “text/plain”.

I made the same observation as @Sebastian, currently the formalism can be anything, and I think we need to have a little control over the set of valid values there, but keeping it flexible so local values can be set.

@Sebastian I also saw the comment about the content to be plain text and kept me think for a minute. I think that just means the content is not binary, not that is text/plain, but interprets XML, JSON, etc. as plain text. Maybe some extra clarification would be good on the specs for that particular comment.

Best,
Pablo.

10

@David, I think the DV_PARSABLE.formalism is not constrained only to MIME types, and has a broader set of possible values. I fact to store something that doesn't have a MIME type but is "parsable", should be specified by other value than "text/plain".

I made the same observation as @Sebastian, currently the formalism can be anything, and I think we need to have a little control over the set of valid values there, but keeping it flexible so local values can be set.

@Sebastian I also saw the comment about the content to be plain text and kept me think for a minute. I think that just means the content is not binary, not that is text/plain, but interprets XML, JSON, etc. as plain text. Maybe some extra clarification would be good on the specs for that particular comment.
[SG] Yes- my understanding as well…just saying that it reads odd in combination with one mime type (/ formalism) of text/plain.
Sebastian

Best,
Pablo.

11

*Von:* openEHR-clinical <openehr-clinical-bounces@lists.openehr.org> *Im
Auftrag von *Pablo Pazos
*Gesendet:* Mittwoch, 4. Juli 2018 09:14
*An:* For openEHR clinical discussions <openehr-clinical@lists.openehr.org
>
*Betreff:* Re: DV_TEXT vs. DV_PARSABLE with formalism "text/plain"

@David, I think the DV_PARSABLE.formalism is not constrained only to MIME
types, and has a broader set of possible values. I fact to store something
that doesn't have a MIME type but is "parsable", should be specified by
other value than "text/plain".

I made the same observation as @Sebastian, currently the formalism can be
anything, and I think we need to have a little control over the set of
valid values there, but keeping it flexible so local values can be set.

@Sebastian I also saw the comment about the content to be plain text and
kept me think for a minute. I think that just means the content is not
binary, not that is text/plain, but interprets XML, JSON, etc. as plain
text. Maybe some extra clarification would be good on the specs for that
particular comment.

*[SG] Yes- my understanding as well…just saying that it reads odd in
combination with one mime type (/ formalism) of text/plain.*

*Sebastian*

Totally agree, will raise a JIRA issue to review the description in the SEC.