just catching up....
> Newton Aird wrote:
>
> Hi,
> I am trying to figure out what should be the correct production in
> the AOM for the following ADL code. What bothers me most is the
> TEXT matches {*} construct.
>
> ELEMENT[at0002] matches { -- Accident or
> exposure
> value matches {
> TEXT matches {*}
> }
> }
>
>
> I have seen this used quit a bit in the sample archetypes, but I
> dont thing the parsed object model from the java parser is correct
> since it makes it a CComplexObject leaf node with RMTypenam of
> TEXT. From the specification I know that CComplexObject should
> only be inner nodes in the AOM. I have queried the online
> documentation and found references to TEXT in the 1.2 adl, but
> nothing in 1.4 that describes what TEXT matches {*}.
>
> I was inclined to assume it should be DvText constrained with the
> regular expression /*/.
>
Put another way, the general pattern
TYPE_NAME matches {*}
is how to constrain an object to be of a certain type, but not constrain
the value in any way
> Hi Newton,
>
> "TEXT matches {*}" basically says a DvText object will be created for
> this node and there is no constraint on the actual value. So what's
> produced from the parser is correct.
>
> But for String constraints cADL has its own syntax. So the ADL should
> be something like the following to be more correct. Then a CString
> node will be created instead.
>
> ELEMENT[at0002] matches { -- A..
> value matches {/*/}
> }
>
> See part 4.4.1 of ADL speficiation for more information.
>
- thomas
--
___________________________________________________________________________________
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)
