Proposed resolution to issue 14

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

During last week's telcon [1] we discussed issue 14 [2] and decided to
move along the lines of the proposal at [3] with the following
modifications:

1) No defaulting of xsi:type
2) No <value> element in the case of GED in property value specification.
3) make xsi:type optional on the <value> element
4) disallow xsi:type on the <property> element when using the compact
form for simple types.

I took an AI to send a new proposal based on [3] with the four agreed
upon changes. New proposal with the agreed changes is below. I also have 
an *additional* proposed modification to that listed below.

-----

SCA property can be defined using the 'type' or the 'element' attribute.
When the 'type' attribute is used, it points to either a XML Schema
simple type or a XML Schema complex type. When the 'element' attribute
is used, it points to a XML Schema global element declaration (GED).
Consequently, a property can be defined using XML Schema simple type,
XML Schema complex type or a XML Schema GED.

* Define a new holder element <value> that can contain a SCA property
value when the property is defined using XML Schema simple or complex type.

* Define a new holder attribute @value that can contain a SCA property
value when the property is defined using XML Schema simple type and has
only one value.

* When a property has multiple values all of them MUST be specified
within the same <property> element. Two sibling <property> elements with
the same value for the @name attribute is an error.

1) Properties defined using XML Schema simple type:

<property name="currency">
    <value xsi:type="xs:string">EURO</value>
    <value xsi:type="xs:string">USDolar</value>
</property>

<property name="pi">
    <value>3.14159265</value>
</property>

When the property is defined using XML Schema simple type and there is
only one property value to set the following simpler syntax can be used:

<property name="pi" value="3.14159265" />

The two forms: either using the <value> element or the @value attribute
are equivalent.

When using the syntax that contains the @value attribute, the attribute
xsi:type MUST NOT be used on the <property> element to specify the type
of the SCA property.

When using the syntax that contains the <value> element, the attribute
xsi:type MAY be used on the <value> element to specify the type of the
SCA property.

2) Properties defined using XML Schema complex type:

<property name="complexFoo">
    <value xsi:type="foo:MyComplexType" attr="bar">
      <foo:a>AValue</foo:a>
      <foo:b>InterestingURI</foo:b>
    </value>
    <value xsi:type="foo:MyComplexType" attr="zing">
      <foo:a>BValue</foo:a>
      <foo:b>BoringURI</foo:b>
    </value>
</property>

<property name="complexBar">
    <value anotherAttr="foo">
      <bar:a>TheValue</bar:a>
      <bar:b>AnotherInterestingURI</bar:b>
    </value>
</property>

The attribute xsi:type MAY be used on the <value> element to specify the
type of the SCA property.

3) Properties defined using XML Schema GED:

<property name="foo">
    <SomeGED ...> ... </SomeGED>
    <SomeGED ...> ... </SomeGED>
</property>

<property name="bar">
    <SomeOtherGED ...> ... </SomeOtherGED>
</property>
-----

My proposed modification:
This proposal is about how one specifies property values. The properties 
themselves are declared somewhere else (typically in componentType). 
Given that the properties have to be declared, I don't see a value to 
including xsi:type in the examples. A runtime has to validate that the 
property value conforms to whatever is specified in the property 
declaration, independent of the value of xsi:type (if present). Given 
this, I would like to suggest that we remove all mention of xsi:type in 
the proposal above (neither encourage or discourage it's use). At the 
very least, I don't see a reason to encourage its use.

[thanks to Ashok for convincing me that we don't need xsi:type]

Comments?

-Anish
--

[1] http://lists.oasis-open.org/archives/sca-assembly/200804/msg00060.html
[2] http://www.osoa.org/jira/browse/ASSEMBLY-14
[3] http://lists.oasis-open.org/archives/sca-assembly/200804/msg00033.html