Minutes
<anish>
SribeNick: Michael Rowley
Roll
57% attendance -- quorum achieved
Agenda bashing
Anish suggests that Issue 1 should be moved earlier in the agenda.
No objectionns
- Moved issue 1 earlier
Approval of Jan 31, 2008 meeting minutes
Action items review
http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/action_items.php
#0021 chairs to follow up with Mary to post the CD docs to OASIS repository
Not done
#0022 chairs to confirm the May f2f date with Jane
Confirmed as May 1 & 2 (Thur & Fri)
#0023 Khanderao: file a new issue for re-writing specs with RFC-2119
Done.
#0024 Martin: to write up a proposal for issue 15 (Define Conformance Targets)
Not Done.
New Issues
Rowley recalls that Mike E didn't agree with ability to override information from the component type side file.
Anish recalls that Mike E also objected to having bpel-specific information in the component type
<Sanjay>
In section 2, line 194 add --
It is also possible to have a component type file that is associated
with the BPEL component implementation. When such a component type file
is present, as specified in [SCA-Assembly], it provides component type
information in addition to what is found by introspection.
SCA finds the ComponentType
For a BPEL process named "foo:bar" by finding any ComponentType document
that has <implementation.bpel qname="foo:bar">, wherever it might be
within the contribution.
We should concentrate on how to find the component type side file for a process, since assembly-36 will handle what can be
in it.
Anish believes that runtimes will not guarantee that there is only one component type file for a process, even if we require
it with a "MUST".
... also noted that this problem is true for everywhere SCA resolves QNames.
... Isn't worried about having BPEL specific information in that side file.
... Suggests allowing them to be anywhere, but perhaps we can also have a means of pointing to one explicitly.
... But there again, that could be done for all QName resolution.
... On a previous call, there was a suggestion that there may be a default location (same URI but with .componentType extension)
and that the component type that is there doesn't have to have <implementation.bpel>
... Anish is suggesting that we could maintain the requirement that it always have implementation.bpel?
Sanjay - what would be the value of the uri in that case?
Anish - even if it is in the default location, you still need the implementation.bpel with the right QName.
SCA finds the ComponentType for a BPEL process named "foo:bar" by finding any ComponentType document that has <implementation.bpel
process="foo:bar">, wherever it might be within the contribution. While the assembly specification allows <implementation.bpel>
to be absent, for SCA BPEL, the component type MUST include an <implementation.bpel> element.
If <implementation.bpel> is not present, then the component type has to have a contribution URI that is identical to the contribution
URI except that the extension has to be changed to ".componentType".
<anish>
here is what I would prefer: 1) A componentType document for a BPEL process definition can be found by using either "process
QName matching" or "contribution URI matching" mechanisms.
If a componentType document cannot be found through either "process QName matching" or "contribution URI matching" mechanism,
SCA infrastructure MUST implicitly generate a componentType document based on the introspection of the implementation BPEL
process definition.
For "process QName matching", a BPEL process (which is identified by a QName) can be matched with any ComponentType document
that has an <implementation.bpel> refers to the same process QName, wherever it might be within the contribution. For example,
if a componentType document has an <implementation.bpel process="foo:bar">, it will be considered a match for a BPEL process
identified by "foo:bar" QName (where the prefix "foo" in both documents are resolved to the same namespace.).
For "contribution URI matching", a BPEL process can be matched with a componentType document of which the contribution URI
is identical to the contribution URI of the BPEL process except of that the extension is changed to ".componentType". For
example, if "file:/scratch/dir1/compositeX/Foo.bpel" is the contribution URI of a BPEL process, then the contribution URI
of a matching componentType document would be: "file:/scratch/dir1/compositeX/Foo.componentType"
If a non-one-to-one relationship is found during matching (e.g. one-to-many or many-to-one), SCA Infrastructure SHOULD signal
an error to users.
<anish>
here is what I would prefer 1) CA finds the ComponentType for a BPEL process named "foo:bar" by finding any ComponentType
document that has <implementation.bpel process="foo:bar">, wherever it might be within the contribution. While the assembly
specification allows <implementation.bpel> to be absent, for SCA BPEL, the component type MUST include an <implementation.bpel>
element.
<anish>
2) there MUST be only one CT file corresponding to a BPEL QName within a contribution
A BPEL process (which is identified by a QName) can be matched with any ComponentType document that has an <implementation.bpel>
refers to the same process QName, wherever it might be within the contribution. For example, if a componentType document has
an <implementation.bpel process="foo:bar">, it will be considered a match for a BPEL process identified by "foo:bar" QName
(where the prefix "foo" in both documents are resolved to the same namespace.).
While the assembly specification allows <implementation.bpel> to be absent, for SCA BPEL, the component type MUST include
an <implementation.bpel> element.
there MUST be only one CT file corresponding to a BPEL QName within a contribution
Rowley moves that the previous three entries be used to resolve issue 2.
No objections -- issue 2 is resolved.
SUMMARY
Resolution: Issue 2 - Does the spec allow a componentType side file with
text -
A BPEL process (which is identified by a QName) can be matched with any ComponentType document that has an <implementation.bpel>
that refers to the same process QName, wherever it might be within the contribution. For example, if a componentType document
has an <implementation.bpel process="foo:bar">, it will be considered a match for a BPEL process identified by "foo:bar" QName
(where the prefix "foo" in both documents are resolved to the same namespace). While the assembly specification allows <implementation.bpel>
to be absent, for SCA BPEL, the component type MUST include an <implementation.bpel> element. There MUST be only one ComponentType
file corresponding to a BPEL QName within a contribution.
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-BPEL TC...' was assumed
statistics: Schreiber found 96 input lines
edits: Schreiber found no text-edit commands
command-scribe: Line 5: Michael Rowley recognized
command-scribe: Schreiber detected that this section was scribed online
system: Transformer: SAXON 9.0.0.2
[End of Schreiber diagnostic output]