# DV_TEXT, strange behaviour?

**Category:** [Reference Implementation: Java (archive)](https://discourse.openehr.org/c/reference-implementation-java-archive/154)
**Created:** 2007-05-19 14:19 UTC
**Views:** 15
**Replies:** 4
**URL:** https://discourse.openehr.org/t/dv-text-strange-behaviour/12398

---

## Post #1 by @system

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

---

## Post #2 by @system

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\.

---

## Post #3 by @system

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=<null>
nodeID=<null>
parent=<null>
anyAllowed=false
path=/data[at0001]/items[at0002]/value/value
]]
anyAllowed=false
path=/data[at0001]/items[at0002]/value/value
]]
rmTypeName=DV_TEXT
occurrences=<null>
nodeID=<null>
parent=<null>
anyAllowed=false
path=/data[at0001]/items[at0002]/value
]]
anyAllowed=false
path=/data[at0001]/items[at0002]/value
]]
rmTypeName=ELEMENT
occurrences=<null>
nodeID=at0002
parent=<null>
anyAllowed=false
path=/data[at0001]/items[at0002]
]

Please find my comments below.

---

## Post #4 by @system

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

Bert

---

## Post #5 by @system

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

---


**Canonical:** https://discourse.openehr.org/t/dv-text-strange-behaviour/12398
**Original content:** https://discourse.openehr.org/t/dv-text-strange-behaviour/12398