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

[Raymond Feng <rfeng@us.ibm.com>]

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,
Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117,
T/L: 367-8117
Apache Tuscany: 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/>"
...>
> >         <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
> > >

S/MIME Cryptographic Signature