External Package

Technical (archive)
1

Some questions from the External package (v0.9)

section 4.1: assumed types. This section is very brief. It's
a bit of an odd section, as important things are left
unstated (i.e. what are the expectations of whitespace for
the STRING type?) while trivial things such as cummutivity
of + are defined.

section 5.3.1, namespace. Why doesn't the valid namespace
character set include such characters as :/&+ that are
valid in URI's?

section 5.3.2 & 5.3.3: ACCESS_GROUP_REF and PARTY_REF inherit
from OBJECT_REF but this isn't stated in the tables. is there
some pattern to when things are and aren't stated in the tables?

section 5.3.5.1. There's a throwaway line at the end of the
section that archetypes can also be identified by ISO OID's.
While I hope that I never see that ;-), it's not clear from
the stated syntax how that would fit in. Nor, while we're here,
is it clear whether it's valid to use some terminology based
identification (such as LOINC for pathology archetypes)

Grahame

2

Grahame Grieve wrote:

Some questions from the External package (v0.9)

section 4.1: assumed types. This section is very brief. It's
a bit of an odd section, as important things are left
unstated (i.e. what are the expectations of whitespace for
the STRING type?) while trivial things such as cummutivity
of + are defined.

I don't know that anything can be said about whitespace in Strings in general, can it?

section 5.3.1, namespace. Why doesn't the valid namespace
character set include such characters as :/&+ that are
valid in URI's?

this seems reasonable - I'll get it added.

section 5.3.2 & 5.3.3: ACCESS_GROUP_REF and PARTY_REF inherit
from OBJECT_REF but this isn't stated in the tables. is there
some pattern to when things are and aren't stated in the tables?

this was an error that the DSTC already found.

section 5.3.5.1. There's a throwaway line at the end of the
section that archetypes can also be identified by ISO OID's.
While I hope that I never see that ;-), it's not clear from
the stated syntax how that would fit in. Nor, while we're here,
is it clear whether it's valid to use some terminology based
identification (such as LOINC for pathology archetypes)

I have to admit, it's not my favourite either - I don't really like OIDs but it seems everyone else does. So archetypes will have two ids: a multi-axial id and an OID (whcih may be optional - we don't know yet). The multi-axial one is defined in detail in the Support RM package 0.9.1 at http://www.deepthought.com.au/health/openEHR/support/support_rm_0_9_1.pdf and I think is a more useful one.

- thomas