Re: [xacml] Comment on XACML Profile for Hierarchical Resources, WD 07

[Anne Anderson <Anne.Anderson@Sun.COM>]

First of all, based on the Minutes of the TC meeting, I am
assuming I should also re-insert the definition of the
xpath-expression DataType in this Profile.  I will re-issue the
Multiple Resources Profile with a reference to the definition of
xpath-expression in this Profile.

In response to your comment:

On 8 September, Michiharu Kudoh writes: Re: [xacml] Comment on XACML Profile for Hierarchical Resources, WD 07
 > Please consider to add the following sentences in Introduction section in
 > order to make two schemes more neutral.
 > 
 > Bill  Parducci writes: Re: [xacml] Comment on XACML Profile for Hierarchical Resources, WD 07
 >> "This profile introduces two different schemes: a scheme that assumes an
 >> XML document is embedded in the XACML request context and a scheme that
 >> does not. The first scheme does not require that the target hierarchical
 >> resource be an XML document. Likewise, the second scheme does not
 >> require the target hierarchical resource _not_ be an XML document. The
 >> request context is an artifact of the implementation and its structure
 >> cannot be used to explicitly derive the structure of the target resource.
 >> 
 >> Simply stated, no direct correlation exists between the structure of
 >> request context and that of the physical resource; ..."
 >> 
 >> besides, the introduction of a few kep prepositions ;o) does this read
 >> better to you?

I completely agree with trying to make the Profile more
representation-neutral, but I would like to quibble with the
proposed phrasing.  The introduction already talks about "three
facilities" (identity, requesting access, stating policies), and
I fear "two different schemes" might be confused with these.

Would the following wording serve?

    This Profile addresses two ways of representing a
    hierarchical resource.  In the first way, the hierarchy of
    which the node is a part is represented as an XML document
    that is included in the the Request, and the requested
    resource is represented as a node in that document.  In the
    second way, the requested resource is not represented as a
    node in an XML document, and there is no representation of
    the hierarchy of which it is a part included in the Request.
    Note that the actual target resource in the first case need
    not be part of an XML document - it is merely represented
    that way in the Request.  Likewise, the target resource in
    the second case might actually be part of an XML document,
    but is being represented in some other way in the Request.
    Thus there is no assumed correlation between the structure of
    the resource as represented in the Request and the actual
    structure of the physical resource being accessed.

Anne

 >> b
 > 
 > Michiharu Kudoh wrote:
 > 
 > >
 > >
 > >
 > > My comment on WD 07 is the following:
 > >
 > > - Section 1, Introduction, line 86
 > > "These facilities are not available for hierarchical resources that are
 > not
 > > XML documents."
 > > I think this sentence might confuse readers. As I said before in the
 > call,
 > > two different schemes introduced in this profile does not mean that one
 > is
 > > designed for dealing with XML document and the other is not. If PEP
 > > converted the hierarchical structure (e.g. file system) into XML format
 > and
 > > put it in the request context, and the policy is specified using XPath on
 > > it, the XML-based scheme is still workable on non-XML resource. Opposite
 > is
 > > the same. That is, it is also possible to specify a policy using
 > > non-XML-based scheme that works on XML document. Thus what I want to have
 > > in Section 1 would be the following:
 > >
 > > "This profile introduces two different schemes: a scheme that assumes XML
 > > document embedded in the XACML request context and a scheme that does not
 > > assume such XML document. The first scheme does not necessarily mean that
 > > the target hierarchical resource should be XML document. In the same way,
 > > the second scheme does not necessarily mean that the target hierarchical
 > > resource should not be XML document. ..."
 > >
 > > Best,
 > > Michiharu
 > 
 > >              To: XACML TC <xacml@lists.oasis-open.org>
 > >              From:  Anne Anderson <Anne.Anderson@Sun.COM>
 > >              Date: 2004/08/28 02:17          
 > >              Subject: [xacml] XACML Profile for Hierarchical Resources, WD 07
 > 
 > > I have submitted an updated XACML Profile for Hierarchical
 > > Resources to the repository.  The link on the XACML TC home page
 > > now points to it.  The document is a zip file containing copies
 > > of the draft in OpenOffice and in PDF formats.
 > >
 > > Changes from WD 05:
 > > - Added URIs to indicate support for "resource-ancestor" and
 > >   "resource-parent" in XML documents and in non-XML resources.
 > > - Expanded introduction.
 > > - Removed definition of xpath-expression dataType (since it is
 > >   defined in Core Spec).
 > > - Minor editorial changes.
 > >
 > > Changes from WD 06:
 > > - Removed URI to indicate support for the "xpath-expression"
 > >   datatype from Section 6.
 > > - Added URIs to indicate support for "resource-parent" and
 > >   "resource-ancestor" to Section 6.
 > >
 > > [Note that I submitted Draft 06, then noticed the errors in the
 > >  profile identifiers section, so made the changes and submitted
 > >  Draft 07.]
 > >
 > > Anne
 > > --
 > > Anne H. Anderson             Email: Anne.Anderson@Sun.COM
 > > Sun Microsystems Laboratories
 > > 1 Network Drive,UBUR02-311     Tel: 781/442-0928
 > > Burlington, MA 01803-0902 USA  Fax: 781/442-1692
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692