sorry I missed this one - didn't get the message in fact - something odd
going on with this list....
Heath Frankel wrote:
>Tom,
>My only comments is related to the resulting XML schema. Any reason we
>couldn't simplify the XML further to the following:
>
> <name xsi:type="DV_CODED_TEXT">
> <value>clinical finding</value>
> <defining_code>SNOMED-CT::404684003</defining_code>
> </name>
>
>
I don't care too much wht the XML looks like - i.e. if it diverges from
the form it should have if strictly following the object structure -
which would be the following:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code><value>SNOMED-CT::404684003</value></defining_code>
</name>
since CODE_PHRASE is still an object; whereas your (neater) XML treats
it as a String field or function of DV_CODED_TEXT. Maybe this is the
solution...to be technically correct, you could even have a new function
or field defined on DV_CODED_TEXT called e.g. defining_code_string, then
your XML would be exactly correct:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code_string>SNOMED-CT::404684003</defining_code_string>
</name>
Even your initial XML is "correct", as long as we are happy to make the
XML-schema diverge from the object model at that level. I think we have
to be resigned to that kind of thing with XML, since otherwise it just
generates too much garbage.
>Having data enclosed within the defining_code element indicates that
>this is
>the value anyway so we don't need the additional value child element.
>The
>only potential downside of this is if there are additional attributes or
>associations added to code_phrase later which would need to then be
>represented as follows:
>
> <name xsi:type="DV_CODED_TEXT">
> <value>clinical finding</value>
> <defining_code>SNOMED-CT::404684003
> <some_other_attribute>some
>data</some_other_attribute>
> </defining_code>
> </name>
>
>Even though the result is still valid XML it is not the normal
>representation in XML.
>
Is the above valid XML? I didn't know you could do that...But it seems
pretty unorthodox, especially if we want to have a clear mapping to
object structures, which I think we should consider the "statement of
truth".
>We would then need to change the schema to
>include the value element again. What is the likelihood of additional
>attributes to Code_Phrase?
>
>Sorry for the discussion of what the XML looks like, but you started it
>:>.
>
>
touch? ;-) The think to keep in mind is to do with paths. We will
obviously use Xpaths in XML data, but we also use Xpath-like paths as
logical paths against objects in memory, and non-XML forms of the data.
We want all these paths to be the same (or let's say, the Xpath-like
openEHR paths to be a nearly strict syntactical subset of the W3C Xpath
syntax). In these paths, ideally we would be able to just reference
something like SNOMED-CT::404684003 rather than having to write stuff like
some_attr [ terminology_id = "SNOMED-CT" AND code_string= "404684003" ]
...well, it seems like a nicer idea, but maybe it doesn't matter that
much? Doing the latter means you can more easily have expressions like:
some_attr [ terminology_id = "SNOMED-CT" AND ( code_string=
"404684003" OR code_string = "404684017") ]
and so on, which Hugh or someone else mentioned here....if we think this
is a distinct possibility, then sticking with the current model may be
better anyway. On the other hand, if we think that the XML instance will
just be too heavy because of this, we should go with the new proposal.
Further thoughts? (Given that we are very close to our 1.0 release date,
I am inclined to leave this as it is, and allow for a divergence in the
XML-schema which enables fewer tags, as in Heath's original piece of XML).
- thomas beale
