Minutes
Administrivia
Persent+ Martin Chapman Oracle Corporation Group Member
Roll - not quorate 16 of 32 voting members Need one more member
Note that lunch will start at 13:00
Agenda - Agreed with the addition of the adoption of prior minutes
Since the meeting is not quorate, we will move on to issue discussion
Assembly-33
In general clients cannot make the assumption that responses will be returned on the same transport connection as the request
N.B. Mr. Nash has arrived so the meeting is now quorate with 17 of 32 voting members
<Mike Edwards>
1) Define an intent that can be handled at the operation level
<Mike Edwards>
2) Specify the effect of the intent on the Bindings
<Mike Edwards>
3) Indicate that there is a potential impact on each C&I specification - and that each C&I spec group should decide on the
impact of this intent on their language specification(s)
<Mike Edwards>
4) Question of the implied interface matching, with the need to match single interfaces with this marking with pairs of interfaces
for call and callback (eg in Java) - and that this should be done in the Assembly TC
<Mike Edwards>
5) Specify the effect of this intent on Policies
<Mike Edwards>
eg - if there are "standard" policy assertions like "encryption" - how are they handled?
<Mike Edwards>
Next agenda item is much lighter weight...
Edwards represents Rowley for discussion of this issue
<Dave Booz>
I think the question is whether or not XML comments are sufficient....i don't feel strongly
<Martin C>
tool don't have to preserve xml comments
<Martin C>
id hope they would preserve elements;)
Mark Combellack2: It would not hurt to be able to add comments to pratically everything. Developers can then document elements
of SCDL as they need.
<Dieter Koenig>
WS-BPEL 2.0 example:
<Dieter Koenig>
parent complex type:
<Dieter Koenig>
<xsd:complexType name="tExtensibleElements">
<xsd:annotation>
<xsd:documentation>
This type is extended by other component types to allow elements and attributes from
other namespaces to be added at the modeled places.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<Dieter Koenig>
all other types extend this:
<Dieter Koenig>
<xsd:complexType name="tProcess">
<xsd:complexContent>
<xsd:extension base="tExtensibleElements">
<xsd:sequence>
Motion: m:Edwards s:Combellack Accept this approach for extending these elements
bob question is that motion correct?
<Mike Edwards>
Agree to add that to the instructions to the editors.
Motion: m:Edwards s:Combellack Resolve Assembly-60 with the proposal contained in the Jira entry
<anish>
Here is a more concrete proposal:
<anish>
<xs:element name="documentation" type="sca:DocumentationType"/>
<xs:complexType name="DocumentationType" mixed="true">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<Dieter Koenig>
WS-BPEL 2.0 type definition:
<xsd:element name="documentation" type="tDocumentation"/>
<xsd:complexType name="tDocumentation" mixed="true">
<xsd:sequence>
<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="source" type="xsd:anyURI"/>
<xsd:attribute ref="xml:lang"/>
</xsd:complexType>
<Mike Edwards>
Adopt the BPEL formulation of the documentation -
common base type which all other complex types derive from
mixed="true"
cardinality 0..n
optional xml:lang
any atttibute
Amendment: m: s: Adopt the BPEL formulation of the documentation -
common base type which all other complex types derive from
mixed="true"
cardinality 0..n
optional xml:lang
any attibute
Amendment: m:Karmarkar s: Adopt the BPEL formulation of the documentation -
common base type which all other complex types derive from
mixed="true"
cardinality 0..n
optional xml:lang
+any
Motion tabled to later today pending action item
Action: Karmarkar to produce a refined proposal containg details and example during the lunch break
<Mike Edwards>
Issue 37: Need to clarify contents of an SCA Domain virtual composite
Assembly-37 Need to clarify contents of an SCA Domain virtual composite
<Dave Booz>
Can we table 37 until my family wakes up?
<Dave Booz>
Anish is doing fine
<Martin C>
just trying to be a nice chair
<Dave Booz>
carry on is ok with me
<Dave Booz>
thanks Martin
<Mike Edwards>
Ron B asks for the capability to wire a composite service to a composite reference
<Mike Edwards>
this would permit a binding remapping
<Mike Edwards>
<discussion of this point>
<Dave Booz>
seperation of the visibility was very key
<Dave Booz>
i'd like to see more of Simon's proposal
<Mike Edwards>
Simon - introduce a new attribute called "connect" which applies to composite level services and component level references
Action: Nash to produce a specific proposal for a new attribute "connect=" that apply to composite level service or a component or
composite level references based on these discussions for consideration later today
<Mike Edwards>
- a composite level service can connect to either a component level service or a composite level refernce
<Mike Edwards>
- a component level reference connects to a composite level reference
<Mike Edwards>
- semantics of connect: for a composite level service, the configuration of the service "is applied to the thing to which
it connects"
<Mike Edwards>
<Simon now admits he needs to write this all down first>
</Simon now admits he needs to write this all down first>
bob asks it it is adequate to create an action on Simon to propose a connect attribute with characteristic along the lines
discussed today due=when?
bob s/attribute/attribute proposal
anish dave, i have no idea if we are still in sync or i've gone in the deep end
Dave Booz anish, having a little trouble parsing all the conversations....if you are suggesting that composite services and
reference cant have bindings then I'm happy
<Mike Edwards>
that is part of what Anish is saying, Dave
<Mike Edwards>
he also says that component services & refences can't have bindings
<Simon Nash>
the suggestion was that composite services do have concrete bindings and they flow down to component services
<Mike Edwards>
if they are not at Domain level
<Dave Booz>
the microphones pick up every noise in the room so secondary conversations are being picked up for the remote folks
<Simon Nash>
sorry that was domain level composite services
Martin C wants to promote a service to beyond its level of competence
<Dave Booz>
BINGO! +1 to Mike R
<Mike Edwards>
Let's deal with "Minutes from the Last Meeting"
<Mike Edwards>
Minutes for 27th May are here:
Action: Update the minutes to change Issue XX to Issue 66
Resolution: Minutes of 2008-05-27 approved with the change that new issue 66 be indicated w/o
Continuation of Assembly-60
<Dieter Koenig>
[1]
-------------- issue 60 xml schema definition proposal --------------
<!-- extension base for all SCA complex types -->
<xsd:complexType name="DocumentationBase">
<xsd:sequence>
<xsd:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="documentation" type="Documentation"/>
<xsd:complexType name="Documentation" mixed="true">
<xsd:sequence>
<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="xml:lang"/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<!-- example usage -->
<xsd:element name="foo" type="anyScaType"/>
<xsd:complexType name="anyScaType">
<xsd:complexContent>
<xsd:extension base="DocumentationBase">
<xsd:sequence>
<xsd:element name="someElement" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="someAttribute" type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
-------------- end of issue 60 xml schema definition --------------
<Mike Edwards>
This complex type becomes the base type for all SCA complex types
<Mike Edwards>
Documentation can be purely String or it can be XML structured data
<Mike Edwards>
- this is the purpose of the mixed="true" and Sequence of <any/>
<Mike Edwards>
ref="xml:lang" allows for multiple languages
Amendment: replacement m:Karmarkar s:Malhotra Resolve Assembly-60 with proposal[1] above. This complex type becomes the base type for
all SCA complex types.
Resolution: Resolve Assembly-60 with proposal[1] above. This complex type becomes the base type for all SCA complex types. w/o
Continuation of Assembly-37
Action: Nash to develop a more concrete proposal along the lines of this discussion so that profitable discussion may continue this
meeting.
Edwards leads the discussion
Action: Chapman to propose some non-normative clarification test to resolve Issue-26 due=2008-12-24
Compliance and Test Suites
Resolution: m:Chapman s:JeffM Direct the editors to label normative statements or groups of statements in the spec w/o
Action: Editors to produce a plan to accomplish the action above due=2008-06-10
Resolution: m:Edwards s:Malhotra to approve actioning test sub-cttee to produce test assertions and test artifacts and test harness w/o
Action: Test sub cttee produce test assertions and test artifacts and test harness
Edwards volunteers to start encouraging members to provide appropriate resources
Booz I have an internal proposal I will post immediatly and can discussed in a short while
Combellack outlines the issue and his proposal
Motion: m:Karmarkar s:Combellack The default value for property manyvalue is false and clarify that the default value of mustsupply
is false
Resolution: Resolve Assembly-62 with the motion above w/o
Motion: m:Nash s:Patil We should not allow customizations of the infoset URI
<Dave Booz>
if this alias concept helps us further seperate deployment endpoint URIs from these infoset URIs, then I'm all for it
Motion: m:Nash s:Patil We should not allow customizations of the synthetic infoset URI
Resolution: We should not allow customizations of the synthetic infoset URI w/o
Action: Edwards to look into the question of aliases
Action: Nash to look into how binding uris may be handled
Schreiber diagnostics output
[Delete this section before publishing the minutes]
citation-detection-scribed: Line 251: Check for possible unrecognized nick 'x/action'
statistics: Schreiber found 232 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 176: anish: s/wsdl:/sca:/
edits: Line 395: bob: s/ook/look
command-scribe: Line 7: Bob Freund recognized
command-scribe: Schreiber detected that this section was scribed online
citation-detection-irc1: Line 127: Check for possible unrecognized nick 'Mark Combellack2'
citation-detection-irc1: Line 134: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 135: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 138: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 139: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 140: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 141: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 142: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 143: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 144: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 145: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 150: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 151: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 152: Check for possible unrecognized nick '<xsd'
edit-substitute: command on line 176 succeeded, changed line 166 from 'wsdl:' to 'sca:'
citation-detection-irc1: Line 168: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 170: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 171: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 172: Check for possible unrecognized nick '</xs'
citation-detection-irc1: Line 173: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 174: Check for possible unrecognized nick '</xs'
edit-delete: Line 176 was deleted
citation-detection-irc1: Line 179: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 180: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 181: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 182: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 183: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 184: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 185: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 186: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 192: Check for possible unrecognized nick 'optional xml'
citation-detection-irc1: Line 201: Check for possible unrecognized nick 'optional xml'
citation-detection-irc1: Line 208: Check for possible unrecognized nick 'optional xml'
citation-detection-irc1: Line 302: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 303: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 304: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 305: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 306: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 308: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 309: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 310: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 311: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 312: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 313: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 314: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 315: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 318: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 319: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 320: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 321: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 322: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 323: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 324: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 325: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 326: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 327: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 328: Check for possible unrecognized nick '</xsd'
edit-substitute: command on line 395 succeeded, changed line 393 from 'ook' to 'look'
edit-delete: Line 395 was deleted
system: Transformer: SAXON 8.9
[End of Schreiber diagnostic output]