regular expressions
I have a question about the ADL-parser concerning the the
regular-expressions.
I checked page 65 in:
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf
Can someone please explain why this fails:
value existence matches {1..1} matches {/[0-9]{1,8}/}
Error:
se.acode.openehr.parser.ParseException: Encountered / / at line
186, column 57.
Was expecting:
} ...
Thanks very much
Bert Verhees
regular expressions
It should work, it is valid ADL
2013/9/23 Bert Verhees bert.verhees at rosa.nl
I have a question about the ADL-parser concerning the the
regular-expressions.
I checked page 65 in:
http://www.openehr.org/**releases/1.0.2/architecture/**am/adl.pdfhttp://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf
Can someone please explain why this fails:
value existence matches {1..1} matches {/[0-9]{1,8}/}
Error:
se.acode.openehr.parser.**ParseException: Encountered / / at line
186, column 57.
Was expecting:
} ...
Thanks very much
Bert Verhees
__**_
openEHR-technical mailing list
openEHR-technical at lists.**openehr.orgopenEHR-technical at
lists.openehr.org
http://lists.openehr.org/**mailman/listinfo/openehr-**
technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/d33770ca/attachment.html
regular expressions
On 09/23/2013 01:29 PM, Diego Bosc? wrote:
It should work, it is valid ADL
It works, I was using an older adl.jj, I updated it, and now it seems to
work.
Sorry for the trouble
Bert
2013/9/23 Bert Verhees bert.verhees at rosa.nl
mailto:bert.verhees at rosa.nl
I have a question about the ADL-parser concerning the the
regular-expressions.
I checked page 65 in:
http://www.openehr.org/releases/1.0.2/architecture/am/adl.pdf
Can someone please explain why this fails:
value existence matches {1..1} matches {/[0-9]{1,8}/}
Error:
se.acode.openehr.parser.ParseException: Encountered / / at
line 186, column 57.
Was expecting:
} ...
Thanks very much
Bert Verhees
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
mailto:openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/d23096f5/attachment.html
Regular expressions?
Mattias Forss wrote:
Hi,
I have noticed that instruction archetypes have different ways of
adding constraints on archetype IDs and domain concepts. Here's an
example:
INSTRUCTION[at] matches {-- Imaging request
activities cardinality matches {0..*; unordered} matches {
ACTIVITY[at0001] occurrences matches {1..*} matches {
-- Imaging activity
action_archetype_id matches {/imaging\.v1/}
description matches {
allow_archetype ITEM_TREE occurrences matches
{0..1} matches {
include
domain_concept matches {/imaging.v1/}
exclude
domain_concept matches {/.*/}
}
}
}
}
}
As you can see for the action_archetype_id the leaf constraint is
/imaging\.v1/ which will correspond to a C_STRING. However, since we
have the
quotation marks the Eiffel parser will probably just add /imaging\.v1/
into the list of the C_STRING (the Java parser will not even parse
this, and fails when it detects the escape character, i.e. \ ).
having outside of // is definitely and error, and will do exactly
what you say.
What I think we want to achieve here is to set the pattern attribute
of C_STRING. Here's a description of the pattern attribute:
pattern: String Regular expression pattern for proposed instances of
String to match.
Now to do this we must remove the quotation marks which gives us:
/imaging\.v1/ which works in the Java parser and sets the pattern
attribute of the CString class.
Now the leaf constraint of action_archetype_id will be more similar to
the archetype slot includes and excludes. However, you will see one
difference. In the include slot (/imaging.v1/) the dot is not escaped,
which in regular expressions means it will match any character and not
just the dot, for example an archetype with the domain concept
imagingav1 would be perfectly legal.
also true, but probably unintended in an archetype id matching expression.
Another issue is whether action_archetype_id should have a regular
expression that matches a domain concept (for any kind of archetype)
or if the regular expression in this case actually should be extended
to /openEHR-EHR-ACTION\.imaging\.v1/ ? I think it would be good if the
regex always started with openEHR-EHR-ACTION in this case, but maybe
the distinction can be made when the rm objects are built...
I would agree with you here as well Mattias. Will add some notes to the
todo list for the tools ;-)
- thomas
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
