Re: [sca-policy] Further Thoughts on Issue 87

[ashok malhotra <ashok.malhotra@oracle.com>]

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
> >