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

[Mike Edwards <mike_edwards@uk.ibm.com>]

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