The context node of hierarchical resources

[Erik Rissanen <erik@axiomatics.com>]

All,

I am looking into the hierarchical and multiple resources profiles again.

They sometimes do not specify the context node of the xpath expressions 
they make use of.

In the hierarchical profile (section 3.1) the context node is said to be 
the "one and only child of the <ResourceContent> element".

First, I suspect that what is really meant is the "one and only child 
element of...". I could be wrong, but if not, then indentation would not 
be possible since indentation are child text nodes.

Second, I propose that we change this to the <Content> element itself in 
3.0. This seems more aesthetic to me. And we get the benefit that the 
top level element of the application data becomes part of the expression 
in the policy.

Consider these two requests (note the lack of indentation):

<Content><Book>
    <Id>1234</Id>
  </Book></Content>

<Content><Patient>
    <Id>1234</Id>
  </Patient></Content>

When the child of the <Content> element is the context node, referring 
to the book id look likes this:

./Id/text()

Referring to the patent id looks like this:

./Id/text()

The two expressions are the same, which could lead to confusion in the 
policies (if they are in the same namespace).

With the <Content> element as the context node:

./Book/Id/text()
vs
./Patient/Id/text()

And they won't collide even if they are in the same namespace, and 
definitely easier for people to understand.

And I don't see the need to limit the resource content to a single 
element. It could be useful to do requests to different resources in the 
same multiple request. Granted, the application could always work around 
this by using an extra "top level" element in all its requests, but this 
is unnecessary overhead.

Regarding any errata for 2.0, I don't think we should change anything. I 
am afraid we would break things in existing implementations. A 
"foolproof" implementation could accept either a single node, or a 
single element surrounded by text nodes. This would inter-operate with 
either interpretation.

Regards,
Erik