Issues
- AOM C_STRING.pattern needs clarification on the regular expression languageSPECPR-377Thomas Beale
- Missing information about temporal constraint validity constraintsSPECPR-374Resolved issue: SPECPR-374Thomas Beale
- AOM1.4 occurrences and cardinalities have some issues and missing semanticsSPECPR-372Thomas Beale
- Three IP items are postulated, but only two are mentioned subsequentlySPECPR-342
- Enable replacement of an internal code set with another in templatingSPECPR-302
- Operand '/=' in rules sectionSPECPR-277Thomas Beale
- C_TERMINOLOGY_CODE.c_conforms_to in spec is not same as ADL WorkbenchSPECPR-243Resolved issue: SPECPR-243Thomas Beale
- Existence matches {0} and further specialization: Should it be removed when flattening?SPECPR-240Thomas Beale
- Minor inconsistencies in ADL2 spec specialisation sectionSPECPR-239Resolved issue: SPECPR-239Thomas Beale
- terminology expression cannot accept SNOMED expressions or READ-codes with DOT'sSPECPR-215
- Allow Human Readable Identifiers (HRID) to have rm_closures starting by numbersSPECPR-208Thomas Beale
- Class EXPR_VALUE_REF not defined but is referred to in EXPR_ARCHETYPE_REFSPECPR-196Resolved issue: SPECPR-196Thomas Beale
- Replace parent_archetype by owner_archetype in ARCHETYPE_TERMINOLOGYSPECPR-193Resolved issue: SPECPR-193Thomas Beale
- Grammar CComplexobject enforces contentSPECPR-192Resolved issue: SPECPR-192Thomas Beale
- Metadata section in grammar does not conform to specsSPECPR-191Thomas Beale
- Possible error in grammar regarding to description in archetype, etc.SPECPR-190Resolved issue: SPECPR-190Thomas Beale
- Ambiguity between ADL and AOM specs concerning duration fractional secondsSPECPR-188Resolved issue: SPECPR-188Thomas Beale
- RESOURCE_DESCRIPTION_ITEM language attribute should come from ISO terminologySPECPR-186Resolved issue: SPECPR-186Thomas Beale
- Ambiguity in CTemporal.pattern_constraintSPECPR-183Resolved issue: SPECPR-183Thomas Beale
- Spec differs from grammarSPECPR-182Thomas Beale
- Problem with syntax like: duration_attr28 matches {Pw/|P38W..P39W4D|}SPECPR-181Thomas Beale
- Archetype_constraint is not equivalent to locatableSPECPR-179Resolved issue: SPECPR-179Thomas Beale
- Problem with language in defining_code assumed valueSPECPR-171Thomas Beale
- Error in grammar Adl.g4SPECPR-167Thomas Beale
- Inconsistent wording and broken links regarding assertionsSPECPR-166Thomas Beale
- ADL grammar for terminology_extracts not yet well defined.SPECPR-163Resolved issue: SPECPR-163Thomas Beale
- AOM2 - property 'code' in ARCHETYPE_TERM has no typeSPECPR-162Resolved issue: SPECPR-162Thomas Beale
- Hard to map ADL2 grammar op rules-packageSPECPR-161Resolved issue: SPECPR-161Thomas Beale
- RULE_ELEMENT not defined in specsSPECPR-160Resolved issue: SPECPR-160Thomas Beale
- Class ASSERTION_VARIABLE refered to in ASSERTION is not found in specsSPECPR-158Resolved issue: SPECPR-158Thomas Beale
- Not possible to extract assumed_value in grammar at c_terminology_codeSPECPR-154Resolved issue: SPECPR-154Thomas Beale
- ADL Grammar does not seem to support defaultValueSPECPR-153Thomas Beale
- AOM2 - missing node_id in all grammar in classes coming from c_complex_objectSPECPR-149Resolved issue: SPECPR-149Thomas Beale
- Relationship second order-derived class and archetype-constraint derived class not clear in specsSPECPR-148Resolved issue: SPECPR-148Thomas Beale
- ADL grammar - error in is_set definition in CardinalitySPECPR-147Resolved issue: SPECPR-147Thomas Beale
- ADL2 default_value in c_defined_object (f.e. c_complex_object) not in grammarSPECPR-146Thomas Beale
- rmTypeName in CObject (CComplexObject) not in grammarSPECPR-145Resolved issue: SPECPR-145Thomas Beale
- CPrimitiveTuple in CAttributeTuple not in grammar.SPECPR-144Resolved issue: SPECPR-144Thomas Beale
- AttrributeId in grammar is not defined in specs.SPECPR-143Resolved issue: SPECPR-143Thomas Beale
- Specification of ADL2 c_primitive_tuple/c_attribute_tuple confusingSPECPR-142Resolved issue: SPECPR-142Thomas Beale
- Missing entry for archetype_tuples in c_complex_object in grammarSPECPR-140Resolved issue: SPECPR-140Thomas Beale
- New AUTHORED_RESOURCE attributes for AOM2SPECPR-138Resolved issue: SPECPR-138Thomas Beale
- Specs-question/remarks/errors collected by Bert VerheesSPECPR-135Resolved issue: SPECPR-135Thomas Beale
- 'uid' fields in Archetypes should be GUIDs only.SPECPR-130
- ADL 1.5 annotation formalismsSPECPR-86Thomas Beale
- Error in description of ARCHETYPE_ONTOLOGY.constraint_definitionsSPECPR-61Resolved issue: SPECPR-61Thomas Beale
- Improving Translation details and other_contributorsSPECPR-24Resolved issue: SPECPR-24Thomas Beale
- Regional translations should fall-back to its parent translation (e.g. en-us to en)SPECPR-22Thomas Beale
- Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.SPECPR-19Resolved issue: SPECPR-19Severin Kohler
49 of 49
AOM C_STRING.pattern needs clarification on the regular expression language
Raise
Analysis
Raise
Analysis
Description
Details
Details
Created November 4, 2021 at 1:14 AM
Updated March 21, 2024 at 12:47 AM
Activity
Show:
Thomas BealeNovember 4, 2021 at 8:41 AM
Usually PERL regex is what we assume in openEHR. I didn’t realise that was not stated in that part of the spec, so we’ll need to update that. Anyway, PREs allow \d, \w etc.
The description of C_STRING.pattern is very vague "Regular expression pattern for proposed instances of String to match." (https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_string_class).
Considering there are many regex languages with different features and levels of compatibility:
https://en.wikipedia.org/wiki/Comparison_of_regular-expression_engines#Language_features
https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#jcc
Though I'm sure our C_STRING.pattern values are not going to be complex regexes, different implementations could choose to use a different regex language, generating incompatibilities at the archetype level.
To avoid this we might:
1. Suggest a preferred language
2. Specify which subset of the regex language should be used
3. If 2. is really small, maybe we can add a syntax/grammar definition to the spec