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

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

Hi, Mike,

Thanks for the clarification. I put
together a sample scenario at [1]. In this case, two composites Composite
1 and Composite 2 are deployed to the SCA domain. Composite 1 includes
Composite 3 while Composite 4 is used as implementation.composite for both
Component1B and Component2B. I have a few questions with some possible
interpretations. 

What are the composites in the info
set to apply the xpath? 

        *
domain composite, composite 1, composite 2 and two copies of composite
4?
        *
domain composite and two copies of composite 4?
        *
or?

Does the xpath apply to Composite 1
and 2 before they are added to the Domain Composite? 
Or do we only evaluate the xpath against
the Domain Composite after the virtual includes are processed?

Can we give a few examples here?

a) Select all top-level components in
the domain: //composite[@name='']/component
b) Select all components in Composite1
(Is it even possible to use the attributes of the <composite>?):
//composite[@name='Composite1']/component
c) Select Component3A: //component[@name='Component3A']
d) Select Component4A on path Component2B/Component4A:
//component[URIRef('Component2B/Component4A')

Thanks,
Raymond
[1] http://svn.apache.org/repos/asf/tuscany/java/sca/modules/policy-builder/src/test/resources/org/apache/tuscany/sca/policy/builder/impl/scenario.png

---

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

---

Mike Edwards <mike_edwards@uk.ibm.com> wrote
on 09/21/2009 04:59:25 AM:

> From:
> 
> Mike Edwards <mike_edwards@uk.ibm.com>
> 
> To:
> 
> "OASIS Policy" <sca-policy@lists.oasis-open.org>
> 
> Date:
> 
> 09/21/2009 05:00 AM
> 
> Subject:
> 
> Re: [sca-policy] Further Thoughts on Issue 87
> 
> 
> Folks, 
> 
> There is a basic misunderstanding that is affecting this debate. 
> 
> It follows from a statement made early on: 
> 
> "My understanding is that we use the domain composite as the
infoset
> to apply the 
> xpath for @attachTo. All included composites have been merged before
> the evaluation." 
> 
> NO.  This is NOT what is meant by the "Infoset for External
Attachment" 
> 
> What it means is ALL SCA Composite files.  Not some tree starting
at
> the Domain Composite, but the set of separate 
> files. 
> 
> So there is NEVER any question of having to recurse into some 
> <implementation.composite/> element. 
> 
> 
> This was the whole point of defining the Infoset for External 
> Attachment in the way described in section 4.4.1. 
> 
> The target of @appliesTo is all the composites in the domain - each
> taken as a composite file and no more. 
> The exceptions are included composites - only the including 
> composites are targeted and then any including 
> is done before evaluating the @appliesTo. 
> 
> There is no humongous tree of composites made up by tracing through
> <implementation.composite/> 
> elements. 
> 
> All that there is is a set of composites - the ones that are used
in
> the Domain. 
> 
> Each composite is taken separately and the XPath of @appliesTo is
> run against that composite, with includes done 
> before the evaluation, if there are any includes. 
> 
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
 
> Email:  mike_edwards@uk.ibm.com 
> 

> 
> From: 
> 
> Raymond Feng <rfeng@us.ibm.com> 
> 
> To: 
> 
> ashok.malhotra@oracle.com 
> 
> Cc: 
> 
> OASIS Policy <sca-policy@lists.oasis-open.org> 
> 
> Date: 
> 
> 17/09/2009 00:23 
> 
> Subject: 
> 
> Re: [sca-policy] Further Thoughts on Issue 87
> 
> 
> 
> 
> 
> I was assuming that "uri" is an attribute for the "component"
> element. But even with that, we still have issues for the inner 
> composite. The following shows the domain composite and inner composite.
> 
> [1] 
> <composite xmlns:ns2="http://ns2"
...>
>  <component name="Component1" uri="Component1">
>        <implementation.composite name="ns2:InnerComposite"/>
>  </component>
> </composite> 
> 
> Applying //component[@uri='Component1/Component2'] against the xml
> still doesn't select Component2 as it is NOT an element in the tree.
> If we inline the inner composite into the domain composite as 
> illustrated below, the it could work. 
> 
> [2] 
> <composite xmlns:ns2="http://ns2"
...>
>   <component name="Component1" uri="Component1">
>   <implementation.composite name="ns2:InnerComposite">
>       <!-- For demo purpose, Inline the inner composite
-->
>       <composite targetNamespace="http://ns2"
name="InnerComposite">
>           <service name="Service1"
promote="Component2/Service1"/>
>           <reference name="ref1"
promote="Component2/ref1"/>
>           <component name="Component2"
uri="Component1/Component2">
>                <implementation.java
class="sample.Component2Impl"/>
>           </component>
>        </composite>
>   </implementation.composite>
>  </component>
> </composite> 
> 
> I'm arguing if we should take [2] instead of [1] as the info set to
> apply the xpath. 
> 
> 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, 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
01:31:20 PM:
> 
> > 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 01:33 PM 
> > 
> > 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
> > > > > > > >
> > 
> > ---------------------------------------------------------------------
> > 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
> > 
> 
> 
> 
> 
> 

> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU 
> 
> 
> 
>

S/MIME Cryptographic Signature