it was very quiet on the call.....
Agenda bashing -- no changes
approval of minutes from 14 feb 2008
No objections to approval of minutes from last week.
Leave AI open and Sanjay will follow up with Mary McRae
AI to define conformance targets -- ongoing
MR: Can someone take an action to update status issue 1
Anish agrees to accept the the AI
Alex, the issues editor is on leave and may not come back
Need to find another issues editor
Any volunteers for issues editor?
Michael Rowley volunteers to be issues editor if he is excused from taking minutes
MR takes on earlier AI assigned to Anish
Action: Rowley to update status of issue 1
Issues 17 -- side file
Anish recaps the state of play
Discussion on uniqueness of partner-link names
MR: We shd agree that one usecase for creating a side file by hand is to disambiguate the partner-link names
I'm now howling
MR: We need some way to point from a component service to the partner-link -- I suggest an XPath
that sounds better
XPath only when absolutely necessary
We can make XPath optional and if not specified we match the name of the service and the partner-link
go cap in hand to the Assembly TC
MR: I lean towards a new namespace for the new attribute
The attribute on the service or reference would either need to be qualified (different from the SCA namespace) or we would
need to add this new attribute to the Assembly spec.
ME: I would like it in the SCA namespace. This will change the Assembly spec.
We already have a BPEL namespace
ME: That's for a different purpose
the bpel namespace is used for attribute that extend bpel - imo, its use should be limited to that
service/@implementationRef would be used to refer to an implementation dependent mechanism to refer to an implementation's
service, if the service name is not sufficient to identify it.
Khanderao requests a private chat with you
MR: We shd not anything that is BPEL specific to the Assembly spec
but I would be OK with adding the above attribute because other implementations, pehaps legacy application would be able to
take advantage of it
Sanjay questions the optionality in above proposal. Don't you need to go one way or another?
I would prefer the generic attribute
MR: This would go on the Service element which is a sibling of implementation
i imagine that this would be xs:string and the fact that this is xpath would be specified in the bpel spec
If you want to use this in the generic case perhaps we need a subelement rather than an attribute?
We are discussing a corner case --- perhsps better to have a proposal to resolve the issue
MR: We are discussing something that the Assembly TC must agree to
MR volunteers to raise an issue in Assembly TC with proposed solution
MR: Can I send the note to 2 TCs?
Best to send separate notes
Action: MR to raise issue with Assembly TC
Hi Ashok, Anish, can you get me on the roll?
Action: MR to propose a partial resolution to the issue using the attribute suggested in earlier action
agree, it won't happen
Concerned abt changing names of services/references in BPEL
MR: Argues why you may want to change names
why change names? why not indirection?
don't see the justification for name change
Please continue discussion of usecases of email.
Issues 14, 15 16, 18 do not have proposals. Please make proposals for these issues
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 87 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 148: charlton: s/chane name/change names/
command-scribe: Line 9: Ashok Malhotra recognized
command-scribe: Schreiber detected that this section was scribed online
citation-detection-irc1: Line 67: Check for possible unrecognized nick 'TITLE'
citation-detection-irc1: Line 68: Check for possible unrecognized nick 'SUBMITTED BY'
edit-substitute: command on line 148 succeeded, changed line 146 from 'chane name' to 'change names'
edit-delete: Line 148 was deleted
system: Transformer: SAXON 184.108.40.206
[End of Schreiber diagnostic output]