MHonArc v2.5.0b2 -->
xacml message
[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]