[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Further Thoughts on Issue 87
Raymond: Re. your example, the spec says: "Where the policySet is intended to be specific to a particular use of a composite file (rather than to all uses of the composite), the structuralURI of a component is used to attach policySet to a specific use of a nested component, as described in the SCA Assembly specification [SCA-Assembly]." Thus, the "structuralURI" of component2 must be used to refer to it. Is this unclear or are you not happy with the solution. All the best, Ashok Raymond Feng wrote: > Hi, Ashok. > > Thank you for sharing your thoughts. I'm running into similar issues. > Please see my comments inline. > > Raymond > ------------------------------------------------------------------------ > *Raymond Feng* > Senior Software Engineer, Apache Tuscany PMC Member & Committer > /IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA > 94404, USA* > E-mail*//: //_rfeng@us.ibm.com_/ <mailto:rfeng@us.ibm.com>/, > *Notes*//: Raymond Feng/Burlingame/IBM, *Tel*//: 650-645-8117, > *T/L*//: 367-8117* > Apache Tuscany*//: //_http://tuscany.apache.org_/ > <http://tuscany.apache.org/>/ > Co-author of Tuscany In Action: //_http://www.manning.com/laws_// / > ------------------------------------------------------------------------ > > > ashok malhotra <ashok.malhotra@oracle.com> wrote on 09/16/2009 > 07:24:21 AM: > > > From: > > > > ashok malhotra <ashok.malhotra@oracle.com> > > > > To: > > > > OASIS Policy <sca-policy@lists.oasis-open.org> > > > > Date: > > > > 09/16/2009 07:26 AM > > > > Subject: > > > > [sca-policy] Further Thoughts on Issue 87 > > > > Issue 87 was raised because the XPath syntax in the example Snippet 3-5 > > in section 3.4 was thought to be > > incorrect. On subsequent checking it turned out that the syntax was, > > indeed, correct. > > An XPath expression that consists of an unadorned element name selects > > all element children of the > > context node with that name. > > You are right. The XPath that doesn't start with / is a relative one. > > > > > The spec (lines 457-458) says "Note that the XPath expression will > > always be evaluated within the context of an attachment considering > > elements where binding instances or implementations are allowed to be > > present. The expression is evaluated against /the parent element of any > > binding or implementation element/." > > > > Thus, if a policySet is attached high at the component level, its > > applicability needs to be examined against the parent element > > of any binding or implementation element. That is, the context node is > > set, in turn to each such parent element and the XPath is then > > evaluated. This seems unduly onerous, so I suggested changing the spec > > to say that the context node > > is the root of the SCDL document. An expression such as //binding.ws > > would then select all binding.ws elements anywhere > > in the SCDL. This seems to me to be significantly simpler to evaluate. > > > > Dave, pointed out that this would not cover included composites and > that > > this was a problem. > > > > On further reflection, I realized that to evaluate the @attachTp in the > > case of external attachment we create an > > */Infoset for External Attachment/* See line 844. This does cover the > > included composites and the @appliesTo in > > policySets could be evaluated using the root of this constructed > InfoSet > > as the context element. > > My understanding is that we use the domain composite as the infoset to > apply the > xpath for @attchTo. All included composites have been merged before > the evaluation. > > > > > What do people think? Details of the construction of the */Infoset for > > External Attachment/* are copied below for > > easy reference. > > > > 1. The Domain is treated as a special composite, with a blank > name > > - "" > > > > 2. Where one composite includes one or more other composites, it > > is the including composite which is addressed by the XPath and its > > contents are the result of preprocessing all of the include elements > > > > --Where the policySet is intended to be specific to a particular > use > > of a composite file (rather than to all uses of the composite), the > > structuralURI of a component is used to attach policySet to a specific > > use of a nested component, as described in the SCA Assembly > > specification [SCA-Assembly]. > > We need to clarify on the "implementation.composite" case. Taking the > following example: > > Domain composite: > <composite xmlns:ns2="http://ns2 <http://ns2/>" ...> > <component name="Component1"> > <implementation.composite name="ns2:InnerComposite"/> > </component> > </composite> > > Inner Composite: > <composite targetNamespace="http://ns2 <http://ns2/>" > name="InnerComposite"> > <service name="Service1" promote="Component2/Service1"/> > <reference name="ref1" promote="Component2/ref1"/> > <component name="Component2"> > <implementation.java class="sample.Component2Impl"/> > </component> > </composite> > > Please note that in the XML infoset of the domain composite, the inner > composite is referenced by QName, > not by the value. That means the XML representation of the inner > composite is not part of the domain composite > document. > > How do we define the xpath to select the Component2 in this case? > Using the domain composite as the root, I don't think > //component[@uri='Component1/Component2'] will find any nodes. > > Do we expect the URIRef function to go beyond one single DOM document? > > > > > --The XPath expression can make use of the unique URI to indicate > > specific use instances, where different policySets need to be used for > > those different instances. > > I think we should clearly define the signature of the XPath functions > such as URIRef, IntentRef. It is not clear what return types > are in the current spec. > > > > > -- > > All the best, Ashok > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]