sca-policy message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-policy] Further Thoughts on Issue 87
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Tue, 22 Sep 2009 10:32:53 +0100
Raymond,
OK, thanks for the reply - and I think
that you may have some useful examples that we can add to the spec.
Comments inline.
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:
| "OASIS Policy" <sca-policy@lists.oasis-open.org>
|
Date:
| 21/09/2009 23:29
|
Subject:
| Re: [sca-policy] Further Thoughts on
Issue 87 |
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?
<mje> It's this second case. Composite1
and Composite2 don't really exist in the configuration - what is there
is the set of
components that they contributed into the
Domain composite - Component1A, Component1B, Component2A, Component2B.
</mje>
* 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?
<mje>
I thought that the Policy spec was explicit
on this point, so your question has me worried that adding stuff to the
Domain composite is
not well described enough (and this is an
issue for the Assembly spec).
Include processing is done FIRST - before
any XPath evaluation. This covers the include processing implied
by the deployment of
composites into the Domain.
</mje>
Can we give a few examples here? <mje>
Sure - and perhaps we can add these to the spec to aid clarity</mje>
a) Select all top-level components in the domain: //composite[@name='']/component
<mje> Yep </mje>
b) Select all components in Composite1 (Is it even possible to use the
attributes of the <composite>?): //composite[@name='Composite1']/component
<mje>There is no obvious way to do
this.</mje>
c) Select Component3A: //component[@name='Component3A']
<mje> Note that this selects
all components with a name Component3A </mje>
d) Select Component4A on path Component2B/Component4A: //component[URIRef('Component2B/Component4A')
<mje> Yes, this selects a specific
use of Component4A - guaranteed unique </mje>
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
>
>
>
>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]