[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Further Thoughts on Issue 87
Raymond: I checked the Assembly spec and I think the URI for Component2 is Component1/Component2 Thus, //component[@uri='Component1/Component2']should find Component2 provided the URI is surfaced as an attribute called URI. Is the problem "How to find a component given its URI" ? All the best, Ashok Raymond Feng wrote: > Do you mind giving me the xpath to select Component2 in my example? > > ------------------------------------------------------------------------ > *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 > 09:11:35 AM: > > > From: > > > > ashok malhotra <ashok.malhotra@oracle.com> > > > > To: > > > > Raymond Feng/Burlingame/IBM@IBMUS > > > > Cc: > > > > OASIS Policy <sca-policy@lists.oasis-open.org> > > > > Date: > > > > 09/16/2009 09:13 AM > > > > 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/> <http://ns2/>" ...> > > > <component name="Component1"> > > > <implementation.composite name="ns2:InnerComposite"/> > > > </component> > > > </composite> > > > > > > Inner Composite: > > > <composite targetNamespace="http://ns2 <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]