On 11/20/2013 12:28 PM, Diego Bosc? wrote:
> Is this for ADL paths? then use ADL path syntax.
> Is this for XML query? then use XPath
>
> No need to reinvent the wheel
I am thinking the same, I was just wondering if there was something
which could be optimized.
But first, let me describe to get to my explanation.
In XML-land, there is only a path-notation which serves for queries,
that is xPath. That is why I think it is not right for expressing paths.
In ADL-land, there is a path-notation which can serve paths-expressions,
and queries, like is described in the Architecture-Overview document.
There is room for erroneous ambiguities in path-definitions, because of
doubled information, and also there are inconsistencies in ADL
path-syntax and there are unnecessary restrictions.
And an archetype is a data-structure description, it should not have
data in it. To define the position of a leafnode, no data or
leafnode-constraints should be used.
One could compare it with XSD, which is the same for XML.
When you have a data-value, how do you define to which node it belongs,
and were that node resides in a complex data-construct.
This is described at page 66 at the Overview-document. But how to use
the first node is not specified. Maybe it is somewhere else.
So this should be, in ADL-path-notation:
/rmtype[an.archetype.id]/data/events[at0006]/data/items[at0004]/value/magnitude
/(by the way, on page 65 in that document is a few times referred to the
attribute archetype_id instead of archetype_node_id (must be a left-over
:) ))/
So the lower-case rm-type is placed, before placing the archetype_id,
while the archetype_id has the rm_type information, even already in his Id.
A chance for ambiguity!
Never demand for information to be written twice!
And also inconsistent, because in case of an archetypeslot, instead of
the lower-case rm-type, the attribute name which contains the slot is used.
Like this
/rmtype[an.archetype.id]/data/events[at0006]/data[an.another.archetype.id]/items[at0004]/value/magnitude
were the attribute "data" has the archetypeid "an.another.archetype.id"
Also this is not nice, because it restricts, and does not tell us what
happens.
It restricts, because it leaves no room for an archetype_node_id, which
can be on the attribute data
(without archetype_node_id it is impossible to refer to it in the ontology)
So following construct would emerge, if wanting data to refer to ontology :
/rmtype[an.archetype.id]/data/events[at0006]/data[at0012][an.another.archetype.id]/items[at0004]/value/magnitude
eventually with an index in it
/rmtype[an.archetype.id]/data/events[at0006]/data[at0012][2][an.another.archetype.id]/items[at0004]/value/magnitude
or
/rmtype[an.archetype.id]/data/events[at0006]/data[at0012,2][an.another.archetype.id]/items[at0004]/value/magnitude
But this is impossible because of removal of the attribute archetype_id,
and having to put the archetype_id in the attribute archetype_node_id.
This is an unnecessary restriction.
------------------------------------------
So, quite some time ago, I came to a way with less restrictions, less
inconsistencies and less chances for erroneous ambiguities.
-If there is an archetype_id, there is no need to mention the rm-type,
because the information is in the archetype_id
-If there is a slot, the attribute to which the slot is placed, is
written as if there was another attribute to follow, just the same as
always.
-In this way there are no restrictions on also mentioning the
archetype_node_id and eventually index.
-An archetypeId in a path can always be recognized by its square
brackets and no accompanying text (rmtype or attributename).
So the example path will be
/[an.archetype.id]/data/events[at0006]/data[at0012]/[an.another.archetype.id]/items[at0004]/value/magnitude
The leading slash is not important and can be omitted.
------------------------------------------
I even had a short notation (I explain this just for fun)
/[an.archetype.id]/{[at0012]}/[an.another.archetype.id]/{[at0004]}/value/magnitude
The curly brackets were needed to distinguish a archetype_node_id from
an archetype_id.
But this short path notation was never used much, not intuitive enough,
I guess. So I forgot it.
------------------------------------------
So, why am I telling all this?
First, I am not happy with the specs, how they define paths, I explained
why.
Second, I am not happy with my own solution, mostly because there is no
consensus, it is a lonely adventure.
And I was not happy with my index-notation, and when to use an
index-notation.
And in that part, you all did help me. I learned to better define and
explain the way I go.
When you look at an archetype, it has a parent-child construction.
When to use an index-notation is when there are two similar children on
one parent, so without index-notation, confusion could occur.
[openEHR-EHR-CLUSTER.bert.v1]/items[at0008][1]/value/value=Jan
[openEHR-EHR-CLUSTER.bert.v1]/items[at0008][2]/value/value=Peter
[openEHR-EHR-CLUSTER.bert.v1]/items[at0009]/value/value=Balkenende
Children are similar if they have the same attribute-name, same
archetype_node_id, the same archetype_id.
But I think that the notation with the comma is better, I am going to
use that.
[openEHR-EHR-CLUSTER.bert.v1]/items[at0008,1]/value/value=Jan
[openEHR-EHR-CLUSTER.bert.v1]/items[at0008,2]/value/value=Peter
[openEHR-EHR-CLUSTER.bert.v1]/items[at0009]/value/value=Balkenende
It is not very important, it is just about defining how to define what
the position of a datavalue/leafnode in the archetype-construct is.
The drawback is that I still need ways to reconstruct paths, etc, for
compatibility reasons.
Thanks for your helping, and if some one wants to discuss it further, I
am still open for that.
It would be a good thing if the OpenEHR community would reconsider the
ways paths are treated
regards
Bert Verhees
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131120/136d221b/attachment.html>
