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

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

If we look at the domain composite:

<composite xmlns: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/>"
...>
    <component name="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">
           
     <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,
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 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/>"
...>
> > > >         <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
> > > > >

S/MIME Cryptographic Signature