Minutes
Administrivia
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
In general clients cannot make the assumption that responses will be returned on the same transport connection as the request
N.B. Member Nash has arrived so the meeting is now quorate with 17 of 32 voting members attending
<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 Combellack>
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>
<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>
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>
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
<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"
bob s/attribute/attribute proposal
<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
<Simon Nash>
sorry that was domain level composite services
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 replacing "XX" 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:Mischkinsky 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: ref Assembly-16 Edwards to look into the question of aliases
Action: ref Assembly-16 Nash to look into how binding uris may be handled
<Mike Edwards>
Anish draws a diagram with 2 contributions, each with a Composite
<Mike Edwards>
Composite A in C1 includes Composite B in C2
<Mike Edwards>
The debate is about whether QName dependencies of B are resolved from the Contents of C2 (and its imports) or from the Contents
of C1 and its imports
<Mike Edwards>
The question is over the case where there is a conflict when there are two versions of the "same" artifact
<Mike Edwards>
Graham Charters makes a point about the difference between include and import
<Mike Edwards>
Potential for a resolution in favour of resolving in the imported contribution, with provisos:
<Mike Edwards>
1) It is an error if there is a conflict with respect to QName resolution - ie the same QName resolves to 2 different things
<Mike Edwards>
2) Import and Export is at the namespace level, not at the QName level - this needs to be spelled out as a warning
<Mike Edwards>
Anish reminds us about Symbol Spaces - same QName can point to different entities - we don't deal with that today
<Mike Edwards>
- this would require a new issue - Anish will deal with this
<michael beisiegel>
3343 11.6.4 get QName Definition
3344 In order to make sense of the domain-level composite (as returned by get Domain-Level
3345 Composite), it must be possible to get the definitions for named artifacts in the included
3346 composites. This functionality takes the supplied URI of an installed contribution (which provides
3347 the context), a supplied qualified name of a definition to look up, and a supplied symbol space (as
3348 a QName, eg wsdl:PortType). The result is a single definition, in whatever form is appropriate for
3349 that definition type.
<michael beisiegel>
3172 namespace (required) For XML definitions, which are identified by QNames, the
3173 namespace should be the namespace URI for the imported definitions. For XML
3174 technologies that define multiple symbol spaces that can be used within one namespace
3175 (e.g. WSDL port types are a different symbol space from WSDL bindings), all definitions
3176 from all symbol spaces are imported.
Action: Edwards to prepare a proposal for addressing Assembly-8 based on some of the discussions
<Dieter Koenig>
WS-BPEL 2.0 definition of partner link type (WSDL extension):
<wsdl:definitions name="NCName" targetNamespace="anyURI" ...>
...
<plnk:partnerLinkType name="NCName">
<plnk:role name="NCName" portType="QName" />
<plnk:role name="NCName" portType="QName" />?
</plnk:partnerLinkType>
...
</wsdl:definitions>
Motion: m:Chapman s:Mischkinsky add interface.partnerLinkType defined in sca bpel to the scdl schema and refernce the defintion from
the Assembly spec
Amendment: m:Anish s: Chapman when we make the assembly spec changes to add a mix of examples to add examples with interface.partnerLinkType
<Dieter Koenig>
[2]sca-bpel-1.1-cd01.xsd:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) OASIS Open 2008. All Rights Reserved.
-->
<schema xmlns="
http://www.w3.org/2001/XMLSchema" targetNamespace="
http://docs.oasis-open.org/ns/opencsa/sca/200712" xmlns:sca="
http://docs.oasis-open.org/ns/opencsa/sca/200712" elementFormDefault="qualified">
<!-- SCA-Assembly XML Schema -->
<include schemaLocation="
http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-schema-200712.xsd"/>
<!-- SCA-BPEL Component Implementation Type -->
<element name="implementation.bpel" type="sca:BPELImplementation" substitutionGroup="sca:implementation"/>
<complexType name="BPELImplementation">
<complexContent>
<extension base="sca:Implementation">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="process" type="QName" use="required"/>
<anyAttribute namespace="##any" processContents="lax"/>
</extension>
</complexContent>
</complexType>
<!-- SCA-BPEL PartnerLinkType Interface -->
<element name="interface.partnerLinkType" type="sca:BPELPartnerLinkType" substitutionGroup="sca:interface"/>
<complexType name="BPELPartnerLinkType">
<complexContent>
<extension base="sca:Interface">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="type" type="QName" use="required"/>
<attribute name="serviceRole" type="NCName" use="optional"/>
<anyAttribute namespace="##any" processContents="lax"/>
</extension>
</complexContent>
</complexType>
</schema>
Motion: (as amended) Resolve Assembly-54 by adding interface.partnerLinkType defined in sca bpel to the scdl schema and refernce the
defintion from the Assembly spec. when we make the assembly spec changes to add a mix of examples to add examples with interface.partnerLinkType
ref[2]
Resolution: Resolve Assembly-54 by adding interface.partnerLinkType defined in sca bpel to the scdl schema and refernce the defintion
from the Assembly spec. when we make the assembly spec changes to add a mix of examples to add examples with interface.partnerLinkType
ref[2] w/o
<anish>
in our implementation we use <wire> elements all over the place. In fact we never use the target attribute
<Martin C>
so why dodnt we get rid of target
<Dave Booz>
i'm liking where Mike E is going
<Ron Barack>
I also think it's OK, but I don't think it conflicts with having redeployment.
<Ron Barack>
ie, what Mike is saying applies if the composite names are different
<Ron Barack>
and redeployment if they are the same.
<Dave Booz>
right, redeployment is now a seperate issue
<Ron Barack>
Dave, would you agree to redeployment?
<Dave Booz>
Ron, I agree that redployment is something we need to address...in the past we've left it as a macro which first undeployed
and then deployed
<Dave Booz>
i want to make sure that runtimes can implement smart redeployment, but I dont think we need to specify the details of those
smarts
<Mike Edwards>
1) When a "new wire" is deployed to the domain, the new wire is an addition to the wiring of the component reference which
it uses as a resource
Deployment of a composite is additive
<Mike Edwards>
so - for x..n references, this simply adds a wire
<Mike Edwards>
but for x..1 references, there are 2 possibilities :
<Mike Edwards>
a) there was not already a wire (either an explicit wire or a target attribute on the reference), then a new wire is added
<Mike Edwards>
b) there was already a wire (either explicit or a target attribute) then it is an error
<Mike Edwards>
the new wire has a replace="true" attribute set
<Mike Edwards>
in which case, the wire REPLACES an existing target attribute on the reference
<Martin C>
do we need a "final" concept
<anish>
cardinality and dynamicity are independent
<Dave Booz>
sure but we dont allow you to specify both
<Dave Booz>
as soon as the deployment lifecycle is different between ref targets and wires, then you've created a seperate concept, the
wire is no longer syntactic sugar for a target
End of discussion on Issue 41 - due to time
Action: Mike Edwards, raise an issue relating to deployment and redeployment and the granularity and semantics of these processes
Action: Question of handling changes of property values (including multi-values) - should be part of this discussion
Motion: m:Rowley s:Nash That a new attribute be introduced into component types and/or components which allow the user to customize
names of service, references or properties. fails A-5, N-10, P-3
Resolution: m:Mischkinsky s:Malhotra Close Assembly-52 with no action w/o
Action: Karmarkar to bring back the resolution of issue 52 back to the BPEL TC
Motion: m:Chapman s:Booz Close Assembly-59 with no action
Amendment: m:Rowley defer consideration until conversations are more developed in the spec
Amendment fails due to lack of a second
Resolution: m:Chapman s:Booz Close Assembly-59 with no action w/o
Action: Nash/Edwards prepare proposal text for Assembly-56
Action: Editors construct a plan for the next CD
Action: Chairs to be sure that JIRA is up to date with the closed issue status in CD1
Next face to face possibly week of September 29-October 3
Action: Members with East Coast facilities consider hosting approximately 18-20 persons
Schreiber diagnostics output
[Delete this section before publishing the minutes]
statistics: Schreiber found 337 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 144: anish: s/wsdl:/sca:/
command-scribe: Line 7: Bob Freund recognized
command-scribe: Schreiber detected that this section was scribed online
citation-detection-irc1: Line 106: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 107: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 110: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 111: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 112: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 113: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 114: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 115: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 116: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 117: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 122: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 123: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 124: Check for possible unrecognized nick '<xsd'
edit-substitute: command on line 144 succeeded, changed line 134 from 'wsdl:' to 'sca:'
citation-detection-irc1: Line 136: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 138: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 139: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 140: Check for possible unrecognized nick '</xs'
citation-detection-irc1: Line 141: Check for possible unrecognized nick '<xs'
citation-detection-irc1: Line 142: Check for possible unrecognized nick '</xs'
edit-delete: Line 144 was deleted
citation-detection-irc1: Line 147: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 148: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 149: 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'
citation-detection-irc1: Line 153: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 154: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 160: Check for possible unrecognized nick 'optional xml'
citation-detection-irc1: Line 211: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 212: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 213: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 214: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 215: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 217: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 218: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 219: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 220: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 221: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 222: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 223: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 224: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 227: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 228: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 229: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 230: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 231: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 232: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 233: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 234: Check for possible unrecognized nick '<xsd'
citation-detection-irc1: Line 235: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 236: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 237: Check for possible unrecognized nick '</xsd'
citation-detection-irc1: Line 365: Check for possible unrecognized nick '<wsdl'
citation-detection-irc1: Line 367: Check for possible unrecognized nick '<plnk'
citation-detection-irc1: Line 368: Check for possible unrecognized nick '<plnk'
citation-detection-irc1: Line 369: Check for possible unrecognized nick '<plnk'
citation-detection-irc1: Line 370: Check for possible unrecognized nick '</plnk'
citation-detection-irc1: Line 372: Check for possible unrecognized nick '</wsdl'
system: Transformer: SAXON 8.9
[End of Schreiber diagnostic output]