Thanks Paul for the feedback,
I agree that there is no reason to limit it to URIs and the profile
should work with any data type, like for regular resource ids.
I am posting this to the TC list for discussion there.
Best regards,
Erik
Tyson, Paul H wrote:
> In the 3.0 draft hierarchical profile of 7 November 2008:
>
> Data type for non-XML node ids (section 2.2) is required to be anyURI.
> While this might be useful to support some xpath-like operations, it
> seems to be overspecified for the basic use case of testing to see if
> one resource is an "ancestor" of another. A string data type would work
> as well.
>
> Consider a resource-id "r1", used in two places in a hierarchy:
>
> http://example.com/path/to/one/r1
> http://example.com/path/to/another/r1
>
> I have a rule that says "permit if resource has ancestor 'path'".
>
> My context handler can supply a bag of resource-ancestor attribute
> values ["one","another","to","path"] for resource-id "r1". But
> according to the draft spec I would have to write the rule:
>
> permit if 'http://example.com/path' anyURI-equal
> resource-ancestor
>
> and the context handler would have to supply URI values like
> 'http://example.com/path', 'http://example.com/path/to', etc.
>
> In other contexts, values like 'path', 'to', etc. would be the actual
> resource-id values for these resources. It would be convenient to use
> these values directly as the values of 'resource-parent',
> 'resource-ancestor', and 'resource-ancestor-or-self'. This would not
> interfere with any existing functionality provided by the hierarchical
> profile, because they would be distinguished by a different datatype.
>
> Please consider relaxing the anyURI datatype requirement for non-XML
> 'resource-parent', 'resource-ancestor', and 'resource-ancestor-or-self'
> attribute values in the hierarchical profile. This would also allow
> policies to use other appropriate comparators besides anyURI-equal and
> regexp-uri-match.
>
> --Paul Tyson
>
>