Title: SCA-Assy - 2008-06-03

Hide IRC

- DRAFT -

SCA-Assembly TC Walldorf, Germany

03 JUN 2008 - 04 JUN 2008

Attendees

Present Mark Combellack, (Avaya, Inc.) Jean Baptiste Laviron, (Axway Software*) Robert Freund, (Hitachi, Ltd.) Eisaku Nishiyama, (Hitachi, Ltd.) Eric Wells, (Hitachi, Ltd.) Bryan Aupperle, (IBM) Michael Beisiegel, (IBM) David Booz, (IBM) Graham Charters, (IBM) Mike Edwards, (IBM) Dieter Koenig, (IBM) Simon Moser, (IBM) Simon Nash, (IBM) Jim Marino, (Individual) Michael Rowley, (Individual) Martin Chapman, (Oracle Corporation) Anish Karmarkar, (Oracle Corporation) Ashok Malhotra, (Oracle Corporation) Jeff Mischkinsky, (Oracle Corporation) Ron Barack, (SAP AG*) Vladislav Bezrukov, (SAP AG*) Sanjay Patil, (SAP AG*) Plamen Pavlov, (SAP AG*) Sabin Ielceanu, (TIBCO Software Inc.)

Chairs Martin Chapman Mike Edwards

Scribe Bob Freund

Agenda: 2008-06-03 08:30 - 09:00 Introduction & administrivia 09:00 - 10:15 Issue 33: Long-Running Request-Response Operations 10:15 - 10:30 Break 10:30 - 10:45 Issue 60: Description elements in SCDL 10:45 - 12:00 Issue 37: Need to clarify contents of an SCA Domain virtual composite 12:00 - 12:30 Issue 26: SCA Composite Visibility 12:30 - 13:30 Lunch 13:30 - 14:30 Compliance & Test Suite 14:30 - 15:30 Issue 16: Component URI is not well described 15:30 - 15:45 Break 15:45 - 16:45 Issue 47: Interface element needs an operation child element 16:15 - 16:45 Issue 62: What is the default value for many and mustSupply on Properties? 16:45 - 17:30 Issue 48: Defaulting composite reference targets to internal components 17:30 - 18:00 Issue 53: No schema or extension model definitions for contributions 18:00 Recess

Agenda: 2008-06-04 09:00 - 10:00 Issue 8: SCDL artifact resolution underspecified 10:00 - 10:15 Issue 54: interface.partnerLinkType 10:15 - 10:30 Break 10:30 - 11:30 Issue 41: Conflicting domain-level deployments (0..n & 1..n cases...) 11:30 - 12:00 Issue 52: @ImplementationRef on Service or Reference to identify appropriate parts of the implementation 12:00 - 12:30 Issue 56: Need to clarify definition of Bidirectional Interfaces 12:30 - 13:30 Lunch 13:30 - 15:00 Issue 59: Conversations with more than 2 participants 15:00 - 15:30 Issue 58: Graphical representation of wires in included composites 15:30 - 15:45 Break 15:45 - 16:45 Work Plan for Specification - towards CD02 16:45 - 18:00 Leave open for follow-up & conclusion 18:00 Adjourn

------------------------------------------------------------------------------

Contents

Topics [1]  Administrivia [2]  Assembly-33 Long-Running Request-Response Operations http://www.osoa.org/jira/browse/ASSEMBLY-33 [3]  Assembly-60 Description elements in SCDL http://www.osoa.org/jira/browse/ASSEMBLY-60 [4]  Assembly-37 Need to clarify contents of an SCA Domain virtual composite http://www.osoa.org/jira/browse/ASSEMBLY-37 [5]  Approval of minutes of 2008-05-27 at http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/28416/SCA%20Assembly%20minutes%202008-05-27.html [6]  Continuation of Assembly-60 [7]  Continuation of Assembly-37 [8]  Assembly-26 SCA Composite Visibility http://www.osoa.org/jira/browse/ASSEMBLY-26 [9]  Compliance and Test Suites [10]  Assembly-16 Component URI is not well described http://www.osoa.org/jira/browse/ASSEMBLY-16 [11]  Issue-62 What is the default value for many and mustSupply on Properties? http://www.osoa.org/jira/browse/ASSEMBLY-62 [12]  Assembly-16 http://lists.oasis-open.org/archives/sca-assembly/200806/msg00004.html [13]  Assembly-8 SCDL artifact resolution underspecified http://www.osoa.org/jira/browse/ASSEMBLY-8 [14]  Assembly-54: interface.partnerLinkType //www.osoa.org/jira/browse/ASSEMBLY-54 [15]  Assembly-41 Conflicting domain-level deployments (0..n & 1..n cases...) http://www.osoa.org/jira/browse/ASSEMBLY-41 [16]  Assembly-52 @ImplementationRef on Service or Reference to identify appropriate parts of the implementation http://www.osoa.org/jira/browse/ASSEMBLY-52 [17]  Assembly-59: Conversations with more than 2 participants http://www.osoa.org/jira/browse/ASSEMBLY-59 [18]  Assembly-56 Need to clarify definition of Bidirectional Interfaces http://www.osoa.org/jira/browse/ASSEMBLY-56

Table of Resolutions

Table of Action Items

------------------------------------------------------------------------------

Action Items

New: 2008-06-03-1: Karmarkar to produce a refined proposal containg details and example during the lunch break 2008-06-03-2: Update the minutes to change Issue XX to Issue 66 2008-06-03-3: Nash to develop a more concrete proposal along the lines of this discussion so that profitable discussion may continue this meeting. 2008-06-03-4: Chapman to propose some non-normative clarification test to resolve Issue-26 due=2008-12-24 2008-06-03-5: Editors to produce a plan to accomplish the action above due=2008-06-10 2008-06-03-6: Test sub cttee produce test assertions and test artifacts and test harness 2008-06-03-7: ref Assembly-16 Edwards to look into the question of aliases 2008-06-03-8: ref Assembly-16 Nash to look into how binding uris may be handled 2008-06-03-9: Edwards to prepare a proposal for addressing Assembly-8 based on some of the discussions 2008-06-03-10: Mike Edwards, raise an issue relating to deployment and redeployment and the granularity and semantics of these processes 2008-06-03-11: Question of handling changes of property values (including multi-values) - should be part of this discussion 2008-06-03-12: Karmarkar to bring back the resolution of issue 52 back to the BPEL TC 2008-06-03-13: Nash/Edwards prepare proposal text for Assembly-56 2008-06-03-14: Editors construct a plan for the next CD 2008-06-03-15: Chairs to be sure that JIRA is up to date with the closed issue status in CD1 2008-06-03-16: Members with East Coast facilities consider hosting approximately 18-20 persons

------------------------------------------------------------------------------

Resolutions

* 2008-06-03-1: Minutes of 2008-05-27 approved with the change that new issue 66 be indicated replacing "XX" w/o * 2008-06-03-2: Resolve Assembly-60 with proposal[1] above. This complex type becomes the base type for all SCA complex types. w/o * 2008-06-03-3: m:Chapman s:Mischkinsky Direct the editors to label normative statements or groups of statements in the spec w/o * 2008-06-03-4: m:Edwards s:Malhotra to approve actioning test sub-cttee to produce test assertions and test artifacts and test harness w/o * 2008-06-03-5: Resolve Assembly-62 with the motion above w/o * 2008-06-03-6: We should not allow customizations of the synthetic infoset URI w/o * 2008-06-03-7: 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 * 2008-06-03-8: m:Mischkinsky s:Malhotra Close Assembly-52 with no action w/o * 2008-06-03-9: m:Chapman s:Booz Close Assembly-59 with no action w/o

------------------------------------------------------------------------------

Minutes

Scribe: Bob Freund

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 <Dieter Koenig> Assembly-33 slides are attached here: http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200805/msg00049.html   Since the meeting is not quorate, we will move on to issue discussion

Assembly-33 Long-Running Request-Response Operations http://www.osoa.org/jira/browse/ASSEMBLY-33

  Koenig presents the slides he has prepared discussing Assembly-33 attached to http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200805/msg00049.html   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...

Assembly-60 Description elements in SCDL http://www.osoa.org/jira/browse/ASSEMBLY-60

  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> <Dieter Koenig> ... <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

Assembly-37 Need to clarify contents of an SCA Domain virtual composite http://www.osoa.org/jira/browse/ASSEMBLY-37

<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

Approval of minutes of 2008-05-27 at http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/28416/SCA%20Assembly%20minutes%202008-05-27.html

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.   Amendment passes w/o 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.

Assembly-26 SCA Composite Visibility http://www.osoa.org/jira/browse/ASSEMBLY-26

  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

<Martin C> FYI: http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html 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

Assembly-16 Component URI is not well described http://www.osoa.org/jira/browse/ASSEMBLY-16

Booz: I have an internal proposal I will post immediatly and can discussed in a short while

Issue-62 What is the default value for many and mustSupply on Properties? http://www.osoa.org/jira/browse/ASSEMBLY-62

  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

Assembly-16 http://lists.oasis-open.org/archives/sca-assembly/200806/msg00004.html

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 <Martin C> recess

Assembly-8 SCDL artifact resolution underspecified http://www.osoa.org/jira/browse/ASSEMBLY-8

<Mike Edwards> http://lists.oasis-open.org/archives/sca-assembly/200804/msg00058.html <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

Assembly-54: interface.partnerLinkType //www.osoa.org/jira/browse/ASSEMBLY-54

<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   Amendment passes w/o <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://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

Assembly-41 Conflicting domain-level deployments (0..n & 1..n cases...) http://www.osoa.org/jira/browse/ASSEMBLY-41

  Barack reviews his presentation attached to http://lists.oasis-open.org/archives/sca-assembly/200806/msg00008.html <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> UNLESS <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

Assembly-52 @ImplementationRef on Service or Reference to identify appropriate parts of the implementation http://www.osoa.org/jira/browse/ASSEMBLY-52

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

Assembly-59: Conversations with more than 2 participants http://www.osoa.org/jira/browse/ASSEMBLY-59

  Rowley argues his case 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

Assembly-56 Need to clarify definition of Bidirectional Interfaces http://www.osoa.org/jira/browse/ASSEMBLY-56

  Edwards channels Rutt 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   adjourned

[End of Minutes] Formatted on 2008-06-05 at 05:01:55 GMT-4

------------------------------------------------------------------------------

Minutes formatted by Schreiber, a collection of XSLT stylesheets by Bob Freund modeled after David Booth's scribe

------------------------------------------------------------------------------

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]