[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Comment on XACML Profile for Hierarchical Resources, WD 07
Speaking about non-XML representation, we should have probably aligned the notional resource axes with XQuery full axes (http://www.w3.org/TR/xquery/#axes) (use ancestor-or-self::resource-id , not resource-ancestors etc. ,add child::resource-id, descendant::resource-id, parent::resource-id, (obviously, as we do not have ordering preceding and following could not be used)) But most definitely that is not worth it to revisit it that late. :) Daniel; -----Original Message----- From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] Sent: Tuesday, September 07, 2004 10:32 AM To: Michiharu Kudoh Cc: XACML TC Subject: Re: [xacml] Comment on XACML Profile for Hierarchical Resources, WD 07 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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro up.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]