[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] change request: namespaces in xpath expressions
Michiharu, The other use of namespace decl I'm aware of is QName for the values of xml attributes, such as "xs:string", and XSLT where namespace prefixes of xpath expressions are expanded when expression is evaluated. If you do not want to use xmlns decl, I agree with your proposal: drop XPathNamespace element from the AttributeSelector and leave it the PolicyDefaults element only. Simon ----- Original Message ----- From: "Michiharu Kudoh" <KUDO@jp.ibm.com> To: <xacml@lists.oasis-open.org> Sent: Saturday, September 28, 2002 8:19 AM Subject: Re: [xacml] change request: namespaces in xpath expressions > > Simon, > Do you know any spec which use xmlns attribute not for complementing the > element name? If yes, I want to see that. If not, I would prefer to have > explicit XPathNamespace element. In the namespace specification, it defines > that namespaces are applied to the element. They are meant to be used by a > validating XML parser. My preference is that we don't add any xmlns > attribute that is irrespective of a validation semantics. If you are > concerned with the semantics of the scope of the XPathNamespace that is > identical to one defined for the xmlns, I am ok to simplify it by removing > XPathNamespace element from AttributeSelector. And PolicyDefaults in Policy > element defines XPathNamespace of Policy and Rule. PolicyDefaults in > PolicySet element defines XPathNamespace of PolicySet. This is much > simpler. It is clearer because policy writer explicitly defines the > namespace expected in the request context. > > 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/28 03:42 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 > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC