[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Further Thoughts on Issue 87
Hi Raymond: I think I understand your concern now. Although the Assembly spec defines a URI scheme to identify embedded composites, the URI does not appear as an attribute and, thus, cannot be used for selection. I believe we need to raise an issue against the Assembly spec. Do you want to do it or shall I raise it? All the best, Ashok Raymond Feng wrote: > If we look at the domain composite: > > <composite xmlns:ns2="http://ns2 <http://ns2/>" ...> > <component name="Component1"> > <implementation.composite name="ns2:InnerComposite"/> > </component> > </composite> > > Applying //component[@uri='Component1/Component2'] against the xml > document above won't find Component2. There are no component elements > in the XML tree whose uri attribute is 'Component1/Component2'. > > What I'm arguing is that the XML infoset for the domain composite > doesn't recursively go into the inner composite used for > "implementation.composite" because the inner composite is referenced > by a QName (similar with the include case, but the spec resolves that > by flattening the included composites first). The xpath only works if > we inline the inner composite by value as illustrated below: > > <composite xmlns:ns2="http://ns2 <http://ns2/> <http://ns2/> > <http://ns2/>" ...> > <component name="Component1"> > <implementation.composite name="ns2:InnerComposite"> > <!-- For demo purpose, Inline the 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> > </implementation.composite> > </component> > </composite> > > Thanks, > 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 > 11:25:12 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 11:27 AM > > > > 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/> > <http://ns2/>" ...> > > > > > <component name="Component1"> > > > > > <implementation.composite > name="ns2:InnerComposite"/> > > > > > </component> > > > > > </composite> > > > > > > > > > > Inner Composite: > > > > > <composite targetNamespace="http://ns2 <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]