Re: [sca-assembly] Proposed resolution to issue 14

[David Booz <booz@us.ibm.com>]

Anish,

+1 to your modification.


And a question, do you have pi memorized to that precision or did you look
it up?


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             Anish Karmarkar                                               
             <Anish.Karmarkar@                                             
             oracle.com>                                                To 
                                       OASIS Assembly                      
             04/21/2008 05:51          <sca-assembly@lists.oasis-open.org> 
             PM                                                         cc 
                                                                           
                                                                   Subject 
                                       [sca-assembly] Proposed resolution  
                                       to issue 14                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php