Cyclic datatypes: OpenEHR virus
Exactly. One of the options when you start a Hangout is to enable live recording to YouTube. You can then go back and edit it if you wish. Otherwise it is streamed and recorded on YouTube. You fill in the metadata and enable publication. That is how all of the HEalthcare IT Live episodes were recorded. https://www.youtube.com/playlist?list=PL5BDmBjSV7CsBYbzNBw-D03WEqSJcWxbP As well as tutorials https://www.youtube.com/playlist?list=PL5BDmBjSV7CvJbk68kWtywDjH25hQ6Ltg On Fri, May 16, 2014 at 3:13 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 16/05/2014 19:10, Timothy W. Cook wrote: On Fri, May 16, 2014 at 2:23 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 16/05/2014 12:35, Timothy W. Cook wrote: Tom gave a good intro to ADL 1.5 on the webinar Tuesday. Maybe Tom knows if they recorded it and posted to YouTube? I don't see a link yet, but in any case, it was pretty rough, so I might do one myself and post it on Youtube. The time has come... Great. May I suggest Google Hangouts? It makes it dead simple to post to YouTube. Tim, do you mean: run a google hang-out and capture that and post it? - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140517/7e8eaefb/attachment.html
Cyclic datatypes: OpenEHR virus
On 17/05/2014 10:44, Timothy W. Cook wrote: Exactly. One of the options when you start a Hangout is to enable live recording to YouTube. You can then go back and edit it if you wish. Otherwise it is streamed and recorded on YouTube. You fill in the metadata and enable publication. That is how all of the HEalthcare IT Live episodes were recorded. https://www.youtube.com/playlist?list=PL5BDmBjSV7CsBYbzNBw-D03WEqSJcWxbP As well as tutorials https://www.youtube.com/playlist?list=PL5BDmBjSV7CvJbk68kWtywDjH25hQ6Ltg Tim, I see I have catching up to do - these are great! Do you have any kind of 'best-of' or compressed version capturing gems of wisdom? (Not that I have a problem with watching the long form, just wondering). Is there a website / wiki with an index of topics covered, questions asked or anything like that? Great work. You're the DJ for e-health ;-) - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140517/44e77232/attachment.html
Cyclic datatypes: OpenEHR virus
I guess I should create some kind of index. Your the second person this week to ask where to start. For the Healthcare IT Live! videos; they are all numbered with the guests name in the title and are listed in the playlist link above. The tutorials, really was supposed to be a series about knowledge modelling but I didn't attract any openEHR or HL7 guests for it. Has a numbered line by line purpose of a MLHIM CCD. Also one video on using the CCD Generator (out of date but still pertinent). There are several other videos, in playlists by category, on the MLHIM Channel https://www.youtube.com/user/MLHIMdotORG HTH, Tim On Sat, May 17, 2014 at 7:57 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 17/05/2014 10:44, Timothy W. Cook wrote: Exactly. One of the options when you start a Hangout is to enable live recording to YouTube. You can then go back and edit it if you wish. Otherwise it is streamed and recorded on YouTube. You fill in the metadata and enable publication. That is how all of the HEalthcare IT Live episodes were recorded. https://www.youtube.com/playlist?list=PL5BDmBjSV7CsBYbzNBw-D03WEqSJcWxbP As well as tutorials https://www.youtube.com/playlist?list=PL5BDmBjSV7CvJbk68kWtywDjH25hQ6Ltg Tim, I see I have catching up to do - these are great! Do you have any kind of 'best-of' or compressed version capturing gems of wisdom? (Not that I have a problem with watching the long form, just wondering). Is there a website / wiki with an index of topics covered, questions asked or anything like that? Great work. You're the DJ for e-health ;-) - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140517/fac0c42e/attachment.html
Cyclic datatypes: OpenEHR virus
On Sat, May 17, 2014 at 9:21 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: well maybe we can take the idea forward with more participants. I had originally thought this effort was centred around only MLHIM (which we need to know more about anyway), but your approach has clearly been much more ecumenical. I'm only sorry that I did not realise earlier. But... let's think about what we can do in the future. There is a lot of useful resource here. Thanks. We could restart the Modelling QA. The Healthcare IT Live! shows took a lot of work and planning each week. I do not have the time right now. It would be great to get some domain experts involved such as Bill Hersh and other clinical informaticians. Maybe one day we will see these universities including knowledge modelling concepts in the informatics courses. There are several other videos, in playlists by category, on the MLHIM Channel https://www.youtube.com/user/MLHIMdotORG Yep, there is a lot of good resource here. I suspect the two things that would be useful for people trying to catch up would be: - an MLHIM 'learning centre' page that summarises tutorial and other learning oriented material (indexes to actual technical specs etc already exist obviously) - a more general multi-level health modelling resources page. Maybe we could host a ring of pages across more than one wiki / website. I know it would take some time, but I would really like to be able to zoom down some index and discover that Fred Trotter was talking about x, y and z, that topic abc was talked about by Stan Huff, Grahame Grieve and whoever else. You get the idea. I still have the show notes from all of the HIT Live! shows. The notes are the planned questions and general topics. I'll see if I can get time to put together an index/overview page. Cheers, Tim Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140517/1eb12558/attachment.html
Cyclic datatypes: OpenEHR virus
On 16-05-14 03:55, pablo pazos wrote:
I mentioned the phases, several times, in my previous messages :)
Maybe Thomas can break that up into more phases.
On 16-05-14 09:16, Thomas Beale wrote:
I think Pablo has summarised some useful things:
* validate based on OPTs - this is a must; it's based on the fact
that all your data are _templated_, not just archetyped
* RM validation pass - you could detect pathological structures at
this point
* archetype (OPT) pass
Nobody should feel bad about having to experiment a bit here. There's
no standard answer yet.
I agree that there is no standard answer, and there will never be one.
There will always be technical progress. That keeps us, developers, at
work. ;-)
I wish more people would discuss their technical working out of the
standards, so we can learn.
I am not familiar with the term OPT. I assume, this is opt-out. As
Pablo gave an example, if some has a DV_TEXT in an archetype, he does
not want a DV_CODED_TEXT at that point.
I agree partly with this. But only if the DV_TEXT is not wildcarded. If
it has an attribute mentioned in the archetype:
DV_TEXT matches { value matches {*} }.
Then there can come nothing but a value-attribute which is a constrained
string, in this case, without constraints. (and if applicable, other
required attributes also)
But if in the archetype is DV_TEXT matches {*} then every attribute is
allowed to use, and it is allowed to derive inheritors from DV_TEXT,
which is DV_CODED_TEXT.
I had this discussion some years ago, at that time you agreed that
inheritance is allowed, according to the standard.
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007041.html
Divergence from the theoretical standard on technical/practical reasons
makes code in the context of that standard less flexible and less
extensible and once diverged code leads to more divergence. It maybe
can even lead to another standard on new premiss, of which I know an
example. But as they say in Fawlty Towers: Never mention the war ;-)
If I misunderstood the term OPTs, please forgive me, it was not with
rhetorical intention.
--
The RM-validation pass is very easy in code. Just check it against the
RM-XSD and let it roll.
Maybe we are not aware, because everything happens in a library. There
may be a performance issue.
Will it be more efficient to check before, what you are checking anyway
afterwards?
Also you do not detect all pathological structures, because the one I
mentioned is perfectly legal in the RM, when DV_TEXT matches {*} is in
the archetype. That makes this example dangerous, it is not possible to
detect by a basic RM-check. But you can find other problems, and have a
quick way out. That is true.
The punishment is for data-sets which are valid, they need more
processor-time to get accepted.
--
I don't understand what is meant with archetype (OPT) pass, so I
cannot comment on that.
-
The one pass situation: the logical path through an archetype is very
hierarchical and very easy.
It is a kind of classical visitor-pattern which is followed, but, in my
case, without unnecessary formalities.
I have rewritten the AOM validation-interpretation three times, every
time to create an XML-validation.
First for XML-Schema, then for RelaxNG, both combined with Schematron.
XML-schema and RelaxNG have shortcomings which are trouble in relation
to the features of the AOM/ADL. Some developers have written workarounds
for that. But that is divergence of the standards.
Now I have rewritten it for schematron-only. But the base-structure
remained the same, just the simple one-pass validation. Schematron seems
to be the best way, for now. The asserts are sorted to the context, so
all tests for a specific node will be done in one group. This avoids, at
validation-time, repeated retrieval of nodes, by the XML-interpreter.
By the way, I have a basic RM-check in my validator, I have converted
the XSD's to Schematron, which is not hard to do. I use it to check for
existence of required attributes, which are not in the archetype, and
check for valid inheritance. But this basic RM validator runs in the
same one-pass validation.
Thanks.
Bert
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/fd52bdb8/attachment-0001.html
Cyclic datatypes: OpenEHR virus
OPT = Operational Template - it's the fully compiled version of a
template. See the Template Designer
http://www.openehr.org/downloads/modellingtools for this - it
generates them. Or else you can just do a fully flattened template in
the ADL 1.5 workbench. I can provide details on this if you need.
- thomas
On 16/05/2014 09:28, Bert Verhees wrote:
On 16-05-14 03:55, pablo pazos wrote:
I mentioned the phases, several times, in my previous messages :)
Maybe Thomas can break that up into more phases.
On 16-05-14 09:16, Thomas Beale wrote:
I think Pablo has summarised some useful things:
* validate based on OPTs - this is a must; it's based on the fact
that all your data are _templated_, not just archetyped
* RM validation pass - you could detect pathological structures at
this point
* archetype (OPT) pass
Nobody should feel bad about having to experiment a bit here. There's
no standard answer yet.
I agree that there is no standard answer, and there will never be one.
There will always be technical progress. That keeps us, developers, at
work. ;-)
I wish more people would discuss their technical working out of the
standards, so we can learn.
I am not familiar with the term OPT. I assume, this is opt-out. As
Pablo gave an example, if some has a DV_TEXT in an archetype, he does
not want a DV_CODED_TEXT at that point.
I agree partly with this. But only if the DV_TEXT is not wildcarded.
If it has an attribute mentioned in the archetype:
DV_TEXT matches { value matches {*} }.
Then there can come nothing but a value-attribute which is a
constrained string, in this case, without constraints. (and if
applicable, other required attributes also)
But if in the archetype is DV_TEXT matches {*} then every attribute is
allowed to use, and it is allowed to derive inheritors from DV_TEXT,
which is DV_CODED_TEXT.
I had this discussion some years ago, at that time you agreed that
inheritance is allowed, according to the standard.
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007041.html
Divergence from the theoretical standard on technical/practical
reasons makes code in the context of that standard less flexible and
less extensible and once diverged code leads to more divergence. It
maybe can even lead to another standard on new premiss, of which I
know an example. But as they say in Fawlty Towers: Never mention the
war ;-)
If I misunderstood the term OPTs, please forgive me, it was not with
rhetorical intention.
--
The RM-validation pass is very easy in code. Just check it against the
RM-XSD and let it roll.
Maybe we are not aware, because everything happens in a library. There
may be a performance issue.
Will it be more efficient to check before, what you are checking
anyway afterwards?
Also you do not detect all pathological structures, because the one I
mentioned is perfectly legal in the RM, when DV_TEXT matches {*} is in
the archetype. That makes this example dangerous, it is not possible
to detect by a basic RM-check. But you can find other problems, and
have a quick way out. That is true.
The punishment is for data-sets which are valid, they need more
processor-time to get accepted.
--
I don't understand what is meant with archetype (OPT) pass, so I
cannot comment on that.
-
The one pass situation: the logical path through an archetype is very
hierarchical and very easy.
It is a kind of classical visitor-pattern which is followed, but, in
my case, without unnecessary formalities.
I have rewritten the AOM validation-interpretation three times, every
time to create an XML-validation.
First for XML-Schema, then for RelaxNG, both combined with Schematron.
XML-schema and RelaxNG have shortcomings which are trouble in relation
to the features of the AOM/ADL. Some developers have written
workarounds for that. But that is divergence of the standards.
Now I have rewritten it for schematron-only. But the base-structure
remained the same, just the simple one-pass validation. Schematron
seems to be the best way, for now. The asserts are sorted to the
context, so all tests for a specific node will be done in one group.
This avoids, at validation-time, repeated retrieval of nodes, by the
XML-interpreter.
By the way, I have a basic RM-check in my validator, I have converted
the XSD's to Schematron, which is not hard to do. I use it to check
for existence of required attributes, which are not in the archetype,
and check for valid inheritance. But this basic RM validator runs in
the same one-pass validation.
Thanks.
Bert
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale
Chief Technology Officer*
+44 7792
Cyclic datatypes: OpenEHR virus
On 16-05-14 12:54, Thomas Beale wrote: OPT = Operational Template - it's the fully compiled version of a template. See the Template Designer http://www.openehr.org/downloads/modellingtools for this - it generates them. Or else you can just do a fully flattened template in the ADL 1.5 workbench. I can provide details on this if you need. Yes, please do. I will read it. Until now, I ignored ADL1.5 Life is difficult enough without it ;-) But I think, time has come to read about it. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/0263da4f/attachment-0001.html
Cyclic datatypes: OpenEHR virus
Tom gave a good intro to ADL 1.5 on the webinar Tuesday. Maybe Tom knows if they recorded it and posted to YouTube? On Fri, May 16, 2014 at 8:21 AM, Bert Verhees bert.verhees at rosa.nl wrote: On 16-05-14 12:54, Thomas Beale wrote: OPT = Operational Template - it's the fully compiled version of a template. See the Template Designerhttp://www.openehr.org/downloads/modellingtoolsfor this - it generates them. Or else you can just do a fully flattened template in the ADL 1.5 workbench. I can provide details on this if you need. Yes, please do. I will read it. Until now, I ignored ADL1.5 Life is difficult enough without it ;-) But I think, time has come to read about it. Bert ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/fcad5c62/attachment.html
Cyclic datatypes: OpenEHR virus
On Fri, May 16, 2014 at 2:23 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 16/05/2014 12:35, Timothy W. Cook wrote: Tom gave a good intro to ADL 1.5 on the webinar Tuesday. Maybe Tom knows if they recorded it and posted to YouTube? I don't see a link yet, but in any case, it was pretty rough, so I might do one myself and post it on Youtube. The time has come... Great. May I suggest Google Hangouts? It makes it dead simple to post to YouTube. Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/0b2f5a73/attachment.html
Cyclic datatypes: OpenEHR virus
On 16/05/2014 19:10, Timothy W. Cook wrote: On Fri, May 16, 2014 at 2:23 PM, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: On 16/05/2014 12:35, Timothy W. Cook wrote: Tom gave a good intro to ADL 1.5 on the webinar Tuesday. Maybe Tom knows if they recorded it and posted to YouTube? I don't see a link yet, but in any case, it was pretty rough, so I might do one myself and post it on Youtube. The time has come... Great. May I suggest Google Hangouts? It makes it dead simple to post to YouTube. Tim, do you mean: run a google hang-out and capture that and post it? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140516/38b2fb3a/attachment.html
Cyclic datatypes: OpenEHR virus
On 14-05-14 12:20, Timothy W. Cook wrote: Precisely. This is why I said before that it is an implementation level issue. Especially in openEHR or anywhere that you are using a DSL and there are not a existing tools to choose from that have been tested across thousands of use cases. I guess, you wanted to say: there are existing tools to choose from that have been tested across thousands of use cases (without not a) In that case, I would be interested in an example use case, one of the thousands, and according tools, I will be happy to learn from you. The implementation programming language, operating system and platform will have an impact on your decisions about allowed recursion depth. So you advice to stop recursion on an arbitrary point? In that case, we have the same strategy, as I already have written a few times last days. Take a look at a Google search for patterns for data validation. Sorry Tim, that is a too easy answer for a man of your qualities. That is not a useful advice, everyone, even children know you can google something. Why do you bother typing this? Bert
Cyclic datatypes: OpenEHR virus
On Wed, May 14, 2014 at 7:56 AM, Bert Verhees bert.verhees at rosa.nl wrote: Take a look at a Google search for patterns for data validation. Sorry Tim, that is a too easy answer for a man of your qualities. That is not a useful advice, everyone, even children know you can google something. Why do you bother typing this? It is not an answer to anything. It is an illustration of how varied the approaches can be based on the implementation situation. -- Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140514/41c2f37b/attachment.html
Cyclic datatypes: OpenEHR virus
On 14-05-14 14:04, Timothy W. Cook wrote: It is an illustration of how varied the approaches can be based on the implementation situation. I tried googling it, of course. I always try to find an answer by myself, before discussing it on a mailinglist. I got 6 million hits to the question you proposed, and the first 30 were not very useful. I would like to see an approach to one specific problem I discussed under this subject-line. And not that approach that I already proposed/explained myself a few times last few days ago. Can you help me there? Thanks, Bert
Cyclic datatypes: OpenEHR virus
On Wed, May 14, 2014 at 11:49 AM, Bert Verhees bert.verhees at rosa.nl wrote: On 14-05-14 16:01, Timothy W. Cook wrote: So please stop breaking in subjects I start, with the purpose to give it a bullshit distraction. Well, excuse the #$% out of me. I didn't know this was Bert's QA list. I thought it was a discussion list for openEHR related technical issues. My comments were certainly appropriate for the topic of data validation. I did not mention MLHIM or even XML. I frankly do not care what you think about MLHIM. Though you are free to express your opinions. I think that *I* am not the angry one here. Kind Regards, Tim Timothy Cook LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook MLHIM http://www.mlhim.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140514/ca82a39d/attachment.html
Cyclic datatypes: OpenEHR virus
If the value is not constrained, the validator should return true without
continuing checking in cascade-recursive mode. For this to work as expected,
the data structure should be validated before than the data validation. The
easiest way of validating the structure is serializing the instance to XML and
using XSD.
Sent from my LG Mobile
Bert Verhees bert.verhees at rosa.nl wrote:
Thomas Beale schreef op 12-5-2014 17:25:
I don't see the problem here; the DV_CODED_TEXT of the
TERM_MAPPING.purpose is always a different instance from the root
DV_TEXT or DV_CODED_TEXT instance. So how can a loop occur?
What I was doing was writing validation-rules for: DV_TEXT matches{*}
I am working on the finishing part of software to write validation-rules
automated, archetypes are translated to validation-rules, and I am doing
the last bits, so I came to this which I had saved in a TODO list.
I had a stack-overflow, and first I thought it was a bug, but after
investigating, I found, it was as designed.
For this situation, I had to write a rule for attribute: mappings, which
can be used, because there is no constraint.
And I wanted to validate the expression completely, so every possible
attribute had to be handled, with occurrence as defined in the
XML-Schema. Attribute: mappings is optional, so it is allowed.
Every attribute that is not a simple type, but a complex OpenEHR-type
needs to be treated the same way (recursive), so in the
mappings-attribute, there is the purpose-attribute which again can have
a mappings-attribute, which again can have purpose-attribute, and so on.
A data-set which would look like that recursive situation would still
match inside the archetype-definition.
Even if this would repeat ten times inside that data-set, it would still
be matching against the archetype.
I admit that the problem is a theoretical one, and I suggested an
automated feeding system, which could create that to make it less
theoretical.
I have seen systems which go to every detail and every bit, thinkable,
automated systems sometimes go very deep.
The problem is, how can validation software distinguish erroneous
nesting from legitimate nesting.
I don't think that is possible, so the validating software has to stop
at a certain arbitrary level of depth.
At a certain point, the validating software will mark a part of a
data-set as erroneous: too deeply nested, even if it still fits inside
the archetype
Then I remembered a teacher from years ago, he said: Don't write perfect
software, write feasible software
But OK, thank you all for your reply's, I am now convinced that it is
not a 100% solvable problem.
best regards
Bert
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Cyclic datatypes: OpenEHR virus
Hello everyone
If it is any more help, here is an earlier discussion on cyclic references:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007015.html
I think that the ADL 1.5 modifications took care of this discrepancy at
the model level as well.
All the best
Athanasios Anastasiou
On 12/05/2014 16:47, Grahame Grieve wrote:
there's usually edge cases in validation where you can stack crash if
you're not really careful (been there many times). That doesn't mean
that the specs are wrong, but if you can clearly describe the case, it
might be worth documenting the risks around it
Grahame
On Tue, May 13, 2014 at 1:25 AM, Thomas Beale
thomas.beale at oceaninformatics.com
mailto:thomas.beale at oceaninformatics.com wrote:
Hi Bert,
On 12/05/2014 15:07, Bert Verhees wrote:
Hi,
I found a peculiarity which causes me some trouble. Not that my
trouble is a problem, I can solve that, but not without breaking
some rules, and the solutions is quite arbitrarily.
The solution is to check if there is any cyclic recursive going
on and break at a certain arbitrary moment. But it is not a nice
solution.
How many times do we see an archetype with an ELEMENT with
DV_TEXT matches {*} in it?
BTW, in ADL 1.5, this is no longer used, the constraint could just
be something like
attr matches {
DV_TEXT
}
if there are no other constraints at all. The semantics are the same
however, so it doesn't change your question.
So, there are almost no constraints at all on that value.
Condition: The validator always needs to check the parents of a
node to find its (parents) attributes, because, the
parents-attributes are legal attributes.
So, in a non-constrained DV_CODED_TEXT, the attributes of
DV_TEXT are valid.
the right way to see this is that the validator needs to be using
the (inheritance-)flattened form of the node, as is available in the
flattened template.
In DV_TEXT a legal attribute is mappings-TERM_MAPPING (because
there are no constraints defined), it is legal to use the
mappings-attribute.
In TERM_MAPPING, there is attribute: purpose- DV_CODED_TEXT,
DV_CODED_TEXT inherits from DV_TEXT, and there is our cycle.
I don't see the problem here; the DV_CODED_TEXT of the
TERM_MAPPING.purpose is always a different instance from the root
DV_TEXT or DV_CODED_TEXT instance. So how can a loop occur? Are you
saying that it could due to buggy software or data? But that's the
same possibility for any data processing framework where a type T
has a property p of type V with a property q of type T... I have to
agree with Tim here, this is probably just about implementation quality.
- thomas
_
openEHR-technical mailing list
openEHR-technical at lists.__openehr.org
mailto:openEHR-technical at lists.openehr.org
http://lists.openehr.org/__mailman/listinfo/openehr-__technical_lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au
mailto:grahame at healthintersections.com.au / +61 411 867 065
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
