findMatchingRMClass

[system]

Hi Rong,

It took me some time before I discovered what this method is for, it is used
in dadl-binding.

It doesn't work reliable for me, often retunring the wrong RMtype, when
stepping hrough the code, I can always explain why.

Isn't it a shortcoming of the dadl-specs, to allow data without rm-type
specification?

I ask this, because, the findMatchingRMClass-method, does not work very
reliable (for me), and also, if this method is used in large amounts of data-
processing, this method with its loops in it must be a pain in CPU-use and
time used.

What is your opinion about this?

Bert

[system]

Bert Verhees schreef:

Hi Rong,

It took me some time before I discovered what this method is for, it is used
in dadl-binding.
  

(it is defined in rm-builder, but used in dadl-binding)

[system]

Hi Rong,

It took me some time before I discovered what this method is for, it is used
in dadl-binding.

It doesn’t work reliable for me, often retunring the wrong RMtype, when
stepping hrough the code, I can always explain why.

Isn’t it a shortcoming of the dadl-specs, to allow data without rm-type
specification?

I ask this, because, the findMatchingRMClass-method, does not work very
reliable (for me), and also, if this method is used in large amounts of data-
processing, this method with its loops in it must be a pain in CPU-use and
time used.

What is your opinion about this?

Hi Bert,

This method is necessary for dADL binding without type information. For some RM classes, there are more than one match of a given mandatory attribute, e.g. “value”. The list of attributes is made available by the constructor annotations. You can look at the testcases for supported look-ups. Sometimes you need to put type information in the dADL text to make the binding explicit.

Cheers,
Rong

[thomas.beale]

All,

I am interested to know what you are using this type matching method for - I have never had to write anyhting like this - in our parser software, we always know what the type of the object is a priori.

• thomas

Rong Chen wrote:

(attachments)

[system]

<br>
I am interested to know what you are using this type matching method
for - I have never had to write anyhting like this - in our parser
software, we always know what the type of the object is a priori.<br>
<br>

There are some untyped dADL-files in the java-project, and I was wondering
if I should support them, this because I want to stay as close as possible
to the java-reference implementation.
But supporting them took me already several days, and was unreliable (in
my case), so I stopped (for now) supporting them, it is very easy to work
around (just put the types in it).

Although, there is a problem. Because want to use dadl as a format for
data-transport, for example from an application to the orm layer (also
passing the rm-builder to create RM-types)
This is OK, when I have everything under control, but I want the kernel I
am writing also to be connectible to software (GUI's, other
data-entry-machines) from third parties, and I want them to use DADL, but
in that case, the spec, which does not require types is working against
me. So if this point could be changed in the spec, I would be happy, but
if it cannot, then I have to live with it (and add an extra restriction).

Bert

[Tim_Cook2 (Tim Cook)]

Hi All,

First of all; I am not a Java programmer.

I have been watching this thread and it is confusing the heck out of
me.

1) What are these "untyped" dADL files; specifically?

2) I have looked at virtually all of the nearly 1200 ADL files in the
openEHR SVN and I do not see anywhere that there is any confusion in the
typing of the defined archetypes or the components therein.

3) Bert: I'm not sure where the confusion is but I would suggest staying
as close to the SPECIFICATIONS as possible irregardless the Java
implementation (if there is a difference).

4) I do not see anywhere in the specifications an attribute called:
findMatchingRMClass So; how and where did you come up with this?

As we are implementing the specs in Python; you Java guys are scaring me
since you have been at this longer than I have and seem to be having
strange difficulties.

Thanks for the feedback.

Cheers,
Tim

[system]

I am not on my working spot right now, so it could be that I remember
something wrong. I answer between your questions

1) What are these "untyped" dADL files; specifically?

These are DADL-fiels which contain only attribute-names and belonging
data, and not the RMtype-na,es to which these attribute belong to.

2) I have looked at virtually all of the nearly 1200 ADL files in the
openEHR SVN and I do not see anywhere that there is any confusion in the
typing of the defined archetypes or the components therein.

They are somewhere in the Java source, there is a sourcetree called
dadl-parser, there you find them in the examples.

3) Bert: I'm not sure where the confusion is but I would suggest staying
as close to the SPECIFICATIONS as possible irregardless the Java
implementation (if there is a difference).

That is my purpose, I stay 100% (except for the dadl-issue) to the
specifications

4) I do not see anywhere in the specifications an attribute called:
findMatchingRMClass So; how and where did you come up with this?

This is a method, you find it in a sourcetree called rm-builder.

As we are implementing the specs in Python; you Java guys are scaring me
since you have been at this longer than I have and seem to be having
strange difficulties.

I don't understand what you mean, there are some java-specific anomalies
java-programmers have to deal with, but they are explained in the document
java-ITS.

If you mean something else specific, I would be very interested what that
is. Thanks.

By the way, is it possible to look at the Python-code, maybe I could learn
from that

regards
Bert

[Tim_Cook2 (Tim Cook)]

If you mean something else specific, I would be very interested what that
is. Thanks.

No. It's probably my lack of knowledge of Java and of the ITS. I
haven't read it in a year or so.

By the way, is it possible to look at the Python-code, maybe I could learn
from that

Of course the code is available on the openEHR SVN server. The project
wiki is at http://www.openehr.org/wiki/display/dev/Python+developer's
+page

As of today the LNCC Workshop http://www.oshipworkshop.if.uff.br/
attendees will be submitting their code updates to the branch at:
http://www.openehr.org/svn/ref_impl_python/BRANCHES/LNCC/
so if you join the mailinglist
http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_python
you can watch for the updates.

The LNCC branch is the newest code.

The ITS is being drafted and it describes how the zope.interface and
zope.schema packages operate. While there is a complete application
server in the project; you will be able to pull out the openehr module
and have on three dependencies outside of Python itself. They are
zope.interface, zope.schema and zope.i18nmessage.

Thanks for asking.

Cheers,
Tim

[system]

Rong Chen schreef:

[system]

Tom,

In the Java implementation, we use this method for finding the type that matches the given attribute list during dADL binding. When parsing dADL text, an intermediate object model is used and then together with the type information the attribute values are sent to rm-builder to construct a tree of RM objects.

The main reason to have this method is because it is not deterministic from attribute list to the original type only based on the type and name of attributes. Most of data types and identification types need explicit type information for binding for this reason. One way to get around this is to include the knowledge of different syntax of string values in the parser. The drawback would be the dADL parser is tightly bond to the RM.

Cheers,
Rong

(attachments)

[thomas.beale]

Hi Rong,

what I am confused about is: where dADL is used in archetypes, the archetype parser should always know what object type it is about to read, e.g. an instance of RESOURCE_DESCRIPTION. Our dADL parser just builds a ‘data tree’ (like an XML DOM tree) and the data tree → Object converter in Eiffel is just given a single root type, and it instantiates that, using the data tree to provide the attribute values. The object type is always passed as a parameter - we didn’t try to write any code that guesses types.

• thomas

Rong Chen wrote:

(attachments)

[system]

OK, now I see where you get the confusion. It’s not in the archetypes parsing where dADL binding is used now. The only concrete use of dADL binding is for loading test fixtures for archetype-testing. Later on, we will need to parse dADL to support ADL 2.0. But as you said, in archetypes the type information is always there. So it’s only in ‘pure’ data binding using dADL we need to figure out the type info (if it’s not specified).

Cheers,
Rong

(attachments)

[thomas.beale]

Rong Chen wrote:

[system]

Rong Chen wrote:

OK, now I see where you get the confusion. It’s not in the archetypes parsing where dADL binding is used now. The only concrete use of dADL binding is for loading test fixtures for archetype-testing. Later on, we will need to parse dADL to support ADL 2.0. But as you said, in archetypes the type information is always there. So it’s only in ‘pure’ data binding using dADL we need to figure out the type info (if it’s not specified).

I would be tempted in that case to enforce a rule whereby there must be a typename at the top level of the dADL document i.e. the top-level object. The only other places type names are needed are when there could be more than one subtype of a statically declared type. We could make these validity rules of dADL texts one day.

I believe this could be a very useful amendment to the dADL specs.

Cheers,
Rong

[system]

Thomas Beale schreef:

Rong Chen wrote:

OK, now I see where you get the confusion. It’s not in the archetypes parsing where dADL binding is used now. The only concrete use of dADL binding is for loading test fixtures for archetype-testing. Later on, we will need to parse dADL to support ADL 2.0. But as you said, in archetypes the type information is always there. So it’s only in ‘pure’ data binding using dADL we need to figure out the type info (if it’s not specified).

You mean, I think, there must be a type name when there is an ambiguity. That sounds clear and reasonable.

However, we are dealing with people, and one thing mentioned in thje specs, is that ADL must be useable by computers, but also by humans.
So, in your suggested solution you are asking at humans to take care that there are no ambiguities in the dADL.

In my opinion it is better to always use typenames, just to be sure, just to not allow people to err with ambiguities.

Bert

[thomas.beale]

Bert Verhees wrote:

Thomas Beale schreef:

Rong Chen wrote:

OK, now I see where you get the confusion. It’s not in the archetypes parsing where dADL binding is used now. The only concrete use of dADL binding is for loading test fixtures for archetype-testing. Later on, we will need to parse dADL to support ADL 2.0. But as you said, in archetypes the type information is always there. So it’s only in ‘pure’ data binding using dADL we need to figure out the type info (if it’s not specified).

You mean, I think, there must be a type name when there is an ambiguity. That sounds clear and reasonable.

However, we are dealing with people, and one thing mentioned in thje specs, is that ADL must be useable by computers, but also by humans.
So, in your suggested solution you are asking at humans to take care that there are no ambiguities in the dADL.

In my opinion it is better to always use typenames, just to be sure, just to not allow people to err with ambiguities.

Bert,
I am not disagreeing that in some circumstances this is a good approach. However it is clearly not always needed, and for that reason I would not want it as a blanket condition in the dADL syntax. I would prefer to add the more limited conditions above, and then for users of particular dADL documents, e.g. Rong’s test cases, to designate that those kind of documents need type markers everywhere to be valid - i.e. a small addition to the syntax for a specific purpose. The way to implement this is to make type markers being optional or mandatory a run time switch on the parser.

• thomas

[system]

Bert,
I am not disagreeing that in some circumstances this is a good approach.
However it is clearly not always needed, and for that reason I would not
want it as a blanket condition in the dADL syntax. I would prefer to add
the more limited conditions above, and then for users of particular dADL
documents, e.g. Rong's test cases, to designate that those kind of
documents need type markers everywhere to be valid - i.e. a small addition
to the syntax for a specific purpose. The way to implement this is to make
type markers being optional or mandatory a run time switch on the parser.

Thanks, Thomas, a switch is a good idea.
Bert