OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] change request: namespaces in xpath expressions


Michiharu,
You are correct, xmlns decl is used for elements and we have data.
Our first problem is that we do not cover all cases with XPathNamespace
element. Also, declaring XPathNamespace in the PolicyDefaults is
equivalent in my opinion to declare namespace prefix on the Policy itself.
So I'd like to use xmlns decl, although it's usage is applied to data.
Simon

----- Original Message -----
From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
To: "Simon Godik" <simon@godik.com>
Cc: <xacml@lists.oasis-open.org>
Sent: Friday, September 27, 2002 5:05 AM
Subject: Re: [xacml] change request: namespaces in xpath expressions


>
> I understand your intention but I am not sure whether or not using
standard
> XML namespace (your first proposal) is really good for our case.
>
> My opinion is that standard XML namespace (you mean xmlns:md
> ="http://www.... record.xsd", right?) should primarily mean the namespace
> for element name of the policy itself. In other words, XACML policy may
> include other namespace (currently seems not but actually we had when SAML
> schema fragment was used in our policy). I think xmlns should be used for
> that case. Since we need to determine the namespace for the value of the
> policy (not element name nor attribute name), it seems reasonable to use
> application-specific namespace designator (XPathNamespace) currently we
> have. How do you think?
>
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
>
>
>
>
>
>                       Simon Godik
>                       <simon@godik.com>        To:
xacml@lists.oasis-open.org
>                                                cc:
>                       2002/09/27 14:04         Subject:  [xacml] change
request: namespaces in xpath expressions
>
>
>
>
>
>
> There are several instances in the policy schema where we pass xpath
> expressions as arguments.
> 1. In the case of <xacml:AttributeSelector> element RequestContextPath
> attribute contains xpath expression
> that selects xacml attribute value from the context.
> 2. When xpath functions are used in the target, the value to match agains
> is xpath expression.
> When xpath functions are used in conditions they take xpath expressions as
> arguments.
>
> All examples are from section 4.2
>
> For the attribute-selector we use XPathNamespace element that maps
> namespace uri to namespace prefix
> (essentially duplicating standard xml namespace declaration)
>
> AttributeSelector:
> <AttributeSelector RequestContextPath=
>     "//ctx:RequestContext/md:record/md:patient/md:policyNumber">
>     <XPathNamespace NamespaceURI="urn:names:tc:xacml:1.0:context" Prefix="
> ctx"/>
>     <XPathNamespace
NamespaceURI="http://www.medico.com/schemas/record.xsd";
> Prefix="md"/>
> </AttributeSelector>
>
> For other uses of xpath functions we do not have special provisions for
> namespace mapping.
> Here is how xpath expression is used in the target to match request:
>
> <ResourceMatch matchId="function:xpath-match">
>     <ResourceAttributeDesignator AttributeId=
>         "urn:oasis:names:tc:xacml:1.0:resource:xpath"/>
>     <AttributeValue>/md:record</AttributeValue>
> </ResourceMatch>
>
> In this case we rely on standard xml namespace declaration for the md
> prefix.
>
> To summarise: we use two methods to deal with the same problem: one is
> standard and one is not.
>
> Proposal:
> 1. Use standard xml namespace declarations mechanism in both cases and
drop
> <XPathNamespace> element.
> 2. Change RequestContextType attribute of AttributeSelector to xs:string
> (it is currently xs:anyURI).
>
> Simon
>
>
>
>
>
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC