>From my point of view, to load a RM meta-model in the ADL/XML/OWL/whatever
parser is still an unappropiate dependance. That would mean that any change
on the RM, if there is any, also implies changing that meta-model for the
parser to correctly work.
In my mind, a dual model system implementation should support a minimal
working environment totally independent of the RM. That is, if I receive an
archetype of a RM that I don't know, I should still be able to parse it and
show it in a minimal form (maybe ugly and redundant, but at least
functional). In fact, I have always thought that the parsing of
C_Domain_Type is not yet a well resolved problem, but that's another topic
:-)
Moreover, if we finally suppose that a meta-model of the RM is available at
the time of parsing, obviously it will be also available at the time of
working with the AOM. And then, coming back to the occurrences problem, why
do we need C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE classes at the AOM? I
mean, why don't just have C_ATTRIBUTE class with its members attribute and
an optional cardinality attribute that will be interpreted as single or
multiple attribute through the RM meta-model?
Maybe a solution could be to add a new keyword such as "container" or
"multiple" to specify that an attribute is multivalued and that has nothing
to do with the cardinality. Maybe something like:
ITEM_TREE[at0001] matches {
items container matches { ... }
}
or if we want to redefine the cardinality:
ITEM_TREE[at0001] matches {
items container cardinality matches {1..*; ordered} matches
{ ... }
}
Just some quick thoughts,
David
2009/7/3 Thomas Beale <thomas.beale at oceaninformatics.com>
> David Moner wrote:
>
> I agree with the initial idea about the optionality of existence,
> occurrences and cardinality; there is no need to state them if they are not
> changed from the reference model.
>
> But one problem arises with the cardinality. As far as I know, the only way
> to differenciate a C_Single_Attribute and a C_Multiple_Attribute while
> parsing the ADL and generating the AOM instance is through the 'existence'
> of the cardinality constraint. If we don't have that keyword it is imposible
> to choose the correct attribute object.
>
>
> yes, that was one of the reasons for making it mandatory originally. The
> way it has to be handled is in the presence of a RM checking component. I
> have implemented this in the reference ADL parser with no problems - by the
> time the compiler reads any ADL text, it as loaded the reference model and
> can find any attribute in it, and detect whether it is a container or not.
>
>
> At the Jira issue we can read "with reference model checking...", but
> making the ADL parsers dependent of the RM is absolutely not a good idea in
> my opinion.
>
>
> not dependent on 'the' RM - just capable of loading any RM. In the
> reference parser, I have implemented a simple meta-model expressed in dADL -
> see this page for details -
> http://www.openehr.org/wiki/display/dev/Machine-readable+model+representations+of+openEHR
> (this will explain why I did not use an XML-schema, to those who will be
> horrified by such an act ;-)
>
> As such, the reference parser now loads any RM you want, and parses any
> archetype against its correct reference model - so there is no dependency.
>
> - thomas beale
>
>
> *
> *
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090703/23e2cb88/attachment.html>
