DV_EHR_URI values suggested in architecture overview are not valid against RFC2396

Description

DV_EHR_URI values are intended to support paths including predicates (e.g. .../content[openEHR-EHR-OBSERVATION.blood_pressure.v1]/data/events[at0xxx]/...
However the square brackets are not supported by RFC2396. I guess it would be necessary to escape these brackets causing horrible looking URIs.

Display friendly EHR URI scheme should be designed.

The applicable BNF from RFC is shown below.

abs_path = "/" path_segments
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f"

PR is addressed in

relates to

Activity

Sebastian Iancu September 30, 2019 at 10:37 AM

fixed in RM 1.0.4

Sebastian Iancu September 30, 2019 at 10:35 AM
Edited

, can this be considered solved in RM 1.0.4? (see CR)

Thomas Beale October 27, 2015 at 2:28 PM

May be useful: there is now a set of URI rules I created in the adl-antlr grammars to represent URIs; slightly simplified from the RFC. See:
https://github.com/openEHR/adl-antlr/blob/master/src/main/antlr/base_patterns.g4

The relevant rules:

// URIs - simple recogniser based on https://tools.ietf.org/html/rfc3986 and
// http://www.w3.org/Addressing/URL/5_URI_BNF.html
URI : URI_SCHEME ':' URI_HIER_PART ( '?' URI_QUERY )? ;
fragment URI_HIER_PART : ( '//' URI_AUTHORITY )? URI_PATH ;
fragment URI_AUTHORITY : ( URI_USER '@' )? URI_HOST ( ':' NATURAL )? ;
fragment URI_HOST : IP_LITERAL | NAMESPACE ;
fragment URI_USER : URI_RESERVED+ ;
fragment URI_SCHEME : ALPHANUM_CHAR URI_XALPHA* ;
fragment URI_PATH : ( '/' URI_XPALPHA+ )+ ;
fragment URI_QUERY : URI_XALPHA+ ( '' URI_XALPHA )* ;

fragment IP_LITERAL : IPV4_LITERAL | IPV6_LITERAL ;
fragment IPV4_LITERAL : NATURAL '.' NATURAL '.' NATURAL '.' NATURAL ;
fragment IPV6_LITERAL : HEX_QUAD (':' HEX_QUAD )* '::' HEX_QUAD (':' HEX_QUAD )* ;

fragment URI_XPALPHA : URI_XALPHA | '+' ;
fragment URI_XALPHA : ALPHANUM_CHAR | URI_SAFE | URI_EXTRA | URI_ESCAPE ;
fragment URI_SAFE : [$@.&_-] ;
fragment URI_EXTRA : [!*"'()] ;
fragment URI_ESCAPE : '%' HEX_DIGIT HEX_DIGIT ;
fragment URI_RESERVED : [=;/#?: ] ;
fragment NATURAL : [1-9][0-9]* ;
fragment HEX_QUAD : HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT ;
// According to IETF http://tools.ietf.org/html/rfc1034[RFC 1034] and http://tools.ietf.org/html/rfc1035[RFC 1035],
// as clarified by http://tools.ietf.org/html/rfc2181[RFC 2181] (section 11)
fragment NAMESPACE : LABEL ('.' LABEL)+ ;
fragment LABEL : ALPHA_CHAR ( NAME_CHAR* ALPHANUM_CHAR )? ;

Thomas Beale June 8, 2015 at 12:14 PM

- certainly more readable. I don't know yet if there are any reasons not to do this - e.g. if there is any accepted standard approach. The %-encoding thing is truly awful, and I think we should avoid it possible.

Sebastian Iancu June 7, 2015 at 8:57 PM

Nowadays RFC2396 is made obsolete by RFC3986. However this issue still exists.
One alternative to ugly percent-encoding is to use ; followed by parameters. See last paragraph on http://tools.ietf.org/html/rfc3986#section-3.3 and also http://www.w3.org/DesignIssues/MatrixURIs.html.
Would this be an acceptable solution?

Done

Details

Reporter

Components

Priority

Created October 15, 2010 at 2:01 AM
Updated February 14, 2024 at 1:28 PM
Resolved September 30, 2019 at 10:37 AM