Re: [sca-assembly] What is the form of an @source XPath expressionwhere the source property is multi-valued?

[Eric Johnson <eric@tibco.com>]

Hi Mike,

Since I just spent some time yesterday looking at XPath questions unrelated to SCA, I figured I'd look at Mike's question.

Along the way, I felt like I started digging a ditch, and nobody was taking the shovel away from me.

First, a typo:

Assembly spec CD05 (PDF), line 1727:
<property name="currency" source="$complexFoo/a"/>

...
but this should be:
<property name="currency" source="$complexFoo/foo:a"/>

It appears that the current form has confused the target namespace of the document with the prefixes in-scope where the XPath expression occurs.  The text following the example should probably be corrected to match.

I also noticed that, although XPath is referenced five times in the spec, and appears to guide normative behavior, there's no normative reference to XPath that would even indicate which *version* of XPath is intended.

Looking through your discussion, and the text of the spec, it does look like we could use a proper formal definition for what it means to define and then evaluate a property.  Not being super familiar with the properties, I'm hesitant to take a full run at the proper text, so here's an attempt that I expect needs much modification.

The @name attribute of a property defines a an XPath variable in scope for the composite document.  The value of the XPath variable is zero or more element nodes.  When a default property value is specified, and not overridden, the value of the XPath variable is defined with the XPath expression "*", where the current node is the property definition.

In the case of a "@file" reference for a property value, this is definitely unclear, and I have no idea what is intended here.  Is the root element of the document supposed to match the "@type" or "@element" of the property?  What if the property is multi-value?  Do we really only want to reference root elements, or do we intend for an XPath into the referenced document?  Maybe there's text in the spec about this, but due to my lack of familiarity in this area, I've missed it.

ASM 50029 is utterly confusing to me.  A small wording change might be appropriate.  I think I know what is intended, but I'm not certain.

Line 4629 - definition of the SCA "value" element seems like it would be invalid.  If a property uses the "@type" form of reference, then the "value" sub-element must be of the type specified by @type.  This schema declaration obscures the fact that the type of "value" is actually different than what it is declared to be, as it validates any content underneath it.  Perhaps we should be encouraging the use of xsi:type in conjunction with the use of @type form - so validation can be done correctly?  And then we should drop the declaration of the "value" element.  Actually, considering further, if we want to keep the "value" element, I think the right thing to do is define it as an abstract element derived from xsd:anyType.  We're truly into the obscure corners of XML Schema here.

I'm hesitant to immediately file formal issues here, because I'm not very familiar with properties, but I agree with Mike that what is currently there leaves plenty of room for confusion.

-Eric.

P.S. Random note: Snippet 8-1 - uses the "sca:" prefix without declaring it.

On 07/21/2010 02:56 AM, Mike Edwards wrote:

OF8136E9A3.E18AD6C0-ON80257767.00349666-80257767.00368ADD@uk.ibm.com" type="cite">
Folks,

OK, here is an interesting question.

SCA component properties support a @source attribute which indicates that the value for the property is obtained from
the value of a property of the containing composite.  The source attribute takes the general form of an XPath expression,
but starting with "$composite_property_name", which indicates the name of the composite property to use, and which
logically implies the "XML document" on which the remainder of the XPath expression operates.

For example:

    <property name="complexType" type="test:ComplexType1"/>
 
    <component name="TestComposite12Component1">
          <implementation.composite name="test:TestComposite71"/>
        <service name="Service1"/>
        <property name="serviceData1" source="$complexType/test:firstData/text()"/>
    </component>

If the composite property is multi-valued (i.e. @many = "true"), what should be the form of the XPath expression in the @source attribute?

    <property name="complexType" many="true" type="test:ComplexType1">
        <value>
                <firstData>Sample first data</firstData>
                <secondData>Sample second data</secondData>
        </value>
        <value>
                <firstData>Alternate first data</firstData>
                <secondData>Alternate second data</secondData>
        </value>
    </property>
 
    <component name="TestComposite76Component1">
          <implementation.composite name="test:TestComposite71"/>
        <service name="Service1"/>
        <property name="serviceData1" source="?????"/>
    </component>

In this case, the composite property contains an array of values.

So, does this imply that the right way to approach this for the @source XPath expression is as follows:

$complexType                                                           --> the whole array of values
$complexType[1]                                                      --> the first value in the array
$complexType[n]                                                      --> the nth value in the array

$complexType[n]/test:firstData/text()                  --> the text in the firstData element of the nth value in the array

and I suppose that since the [...] syntax in XPath is actually a Predicate rather than simply an array index, this
can imply other expressions being contained within the brackets, such as @foo="bar", which would select
the value elements in the array which happen to have thier @foo attribute set to "bar".


I am asking this since our spec is silent on this point and our @source expression format is not straight XPath
but has this twist of having the target property name at its root.


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

---

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