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

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

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,
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 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"
...>
        <component
name="Component1">
           
    <implementation.composite name="ns2:InnerComposite"/>
        </component>
</composite>

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>

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