DV_TEXT, strange behaviour?

Reference Implementation: Java (archive)
1

Hi,

I noticed some strange behaviour, which I cannot explain.

I ask a question before in the same context, which Heath was so kind to
answer.
But further investigating I found out, the question was not answered,
but the question also was wrong.

So I try again

I have three ELEMENT(s) like this:

ELEMENT[at1.1.2.2] matches { -- A
    value matches {
        DV_TEXT matches {
            value matches {"123"}
        }
    }
}
ELEMENT[at1.1.4.4] matches { -- B
    value matches {
        DV_TEXT matches {*}
    }
}
ELEMENT[at1.1.4.3] matches { -- C
    value matches {
        DV_DATE matches {
            value matches {yyyy-??-??}
        }
    }
}

The first (A) and the third (C) should give objects deeper then DV_DATE
or DV_TEXT, because there is an attribute below
The second (B) one should stop at DV_TEXT, because it does nothing with
attributes.

I was analyzing this, but I discovered the ELEMENT(s) do not behave like
I expect (which can be a problem of my expectations)

I am writing a recursive data/archetype analyzer, and I do some log-output:
ELEMENT A does:
        RmTypeName: ELEMENT
        NodeID: at1.1.2.2
        Path:
/identities[at1]/details[at1.1]/items[at1.1.2]/items[at1.1.2.2]
        Occurrences: null
        -------Attributes------
        CSingleAttribute-alternatives: DV_TEXT: null
        
path:/identities[at1]/details[at1.1]/items[at1.1.2]/items[at1.1.2.2]/value

2

Hi, message below, I posted exact a week ago. I got not reply at all. It
is an important question for me, that is why I post it again.

I will rewrite it in hope it does not scare people, or it is hard to
udnerstand.
It can be a bug in the ADL-parser for Java, but it alsso can be a
misunderstanding on my behalf.

Please, if your emailer does not display this in a non-proportional font
(like courier), please copy and paste it to notepad, else, the layout
will be (kind of) distorted and hard to understand

So let me please explain.

3

Hi Bert,

Sorry for the delay. I tried the (A) with the parser on the Trunk, the toString output seems to be OK (see below). Maybe the parser you are using is out-of-date?

Regards,
Rong

org.openehr.am.archetype.constraintmodel.CComplexObject@b42cbf [
attributes=[org.openehr.am.archetype.constraintmodel.CSingleAttribute@76cbf7[
rmAttributeName=value
existence=REQUIRED
children=[org.openehr.am.archetype.constraintmodel.CComplexObject@3bb2b8[
attributes=[ org.openehr.am.archetype.constraintmodel.CSingleAttribute@152544e[
rmAttributeName=value
existence=REQUIRED
children=[org.openehr.am.archetype.constraintmodel.CPrimitiveObject@1cdeff[
item=org.openehr.am.archetype.constraintmodel.primitive.CString@cec0c5
rmTypeName=String
occurrences=
nodeID=
parent=
anyAllowed=false
path=/data[at0001]/items[at0002]/value/value
]]
anyAllowed=false
path=/data[at0001]/items[at0002]/value/value
]]
rmTypeName=DV_TEXT
occurrences=
nodeID=
parent=
anyAllowed=false
path=/data[at0001]/items[at0002]/value
]]
anyAllowed=false
path=/data[at0001]/items[at0002]/value
]]
rmTypeName=ELEMENT
occurrences=
nodeID=at0002
parent=
anyAllowed=false
path=/data[at0001]/items[at0002]
]

Please find my comments below.

4

Hi Rong, I am a week on holiday now, I reply to this next week.
Thank you for looking into this

Bert

5

Rong Chen schreef:

Hi Bert,

Sorry for the delay. I tried the (A) with the parser on the Trunk, the
toString output seems to be OK (see below). Maybe the parser you are
using is out-of-date?

You are right, it must have been that I missed some lately
parser-improvement. your parsed object is different from mine, it has
the CString-item, which I was missing in my version.
It must have been because I cannot use your code directly, because my
code-tree is not the same as yours, but I always have manually to
consider if I can take over your improvements. That makes it a bit
difficult. So, sorry for bothering you with this problem

Thanks again for your looking into it.

Bert