Minutes approved
All action items completed except RPC issue.
RPC issue is Issue 45, "is RPC a module or not?". Also there was some question as to the charter of the RPC sub-group.
David Fallside: Acronym poll resulted in "XMLP" being chosen with a large majority. XMLP will be the acronym used in our documents and otherwise.
David Fallside: Attorney's recommend that the more we use the acronym the better a claim we will have on the acronym if someone were to challenge it.
David Fallside: Try to get agreement in this call on the glossary that we can publish as part of the Requirements document to satisfy heartbeat document requirement.
David Fallside: Outstanding definitions to resolve: "Block", "Handler", "Module".
Henrik: The Abstract Model group is discussing this.
Henrik: 2 parts of a block the part on the wire and the handler, the module is the composition of the two.
David Clay: can a block have more than one handler?
Answer: Yes. There is a many-to many relationship. A block can be handled by multiple handlers, in sequence.
Question: I thought we agreed that the handler was the encapsulation and the module were the rules? Has that changed.
Henrik: No. The previous definition that was in the requirements document that went out after the F2F was that a Module is a bag with one or more handlers or blocks. The module is a set of rules, they are instantiated into blocks and they are instantiated into how you generate the blocks. So the differences are small.
David Fallside: If you look at the table the original text is there and it is similar.
Question: Does the block encompass both the header and the body of an XML envelope?
Henrik: We haven't changed that from the previous glossary. You can have blocks in both headers and bodies.
Issue: We say that a module has rules for processing things without rules are to be described. Should modules be described with English text specification, or what? We want to be able to describe a module such that people can implement it and that it will interoperate, etc.
Henrik: Yes that is a topic of discussion. Currently we are not specifying how the rules should be specified or how to map those rule specifications to implementations. We won't get into what those
Scott: Isn't someone defining a template for defining modules.
David Clay: Yes. That is due next week.
Marwan: In the case of RPC it would be good if everyone implemented that module in the same fashion.
Q: Have we decided that RPC is, in fact, a module?
David Fallside: That is still an outstanding issue.
David Fallside: Guidance to David Clay and Glen Daniels -- Note for deliberations of template for the protocol module that a reference needs to be made to the notion of processing rules in the glossary definition. We need to tie these back to each other.
DF: For purposes of glossary do those definitions suffice.
Henrik: I would say so.
Q: In the sense that they are internally self consistent?
Answer: Yes. That is the hope. However, we are being circular in some cases. Which may be what we want (?) towards being abstract...
Comment: Its pretty easy to visualise an active machine which is the handler, and the rules by which that machine operates, and the definition of the template of the actual physical things that the machine eats. The handler and the rules are the module and the thing that the machine eats (and spits out) are the blocks.
David Clay: Why do we have multiple handlers in a module?
Glen Daniels: Handler term may have come from Axis project. Each handler does piece of work that handles one or more blocks. Module can have more than one handler. Handler can be used by more than one module.
David Clay: Do you mean that they are in the same module because they interact in some way.
GD: Yes
DF: Do we believe that this is necessary for higher-level modules that might use us?
Henrik: For the purpose of this definition, what we have is close enough.
GD: It would be a good exercise to take some concrete examples and apply the Abstract Model "machine" to them.
Response: General agreement. Perhaps do so with some of our scenarios.
David Clay: That would he would help to clarify this issue of whether we need multiple handlers in a module or not.
Comment: Multiple handlers would be useful in case of distributed transactions and reliable messaging. The parts that handle each may need to interact.
Comment: Wouldn't those be separate modules?
Comment: We need to make what we specify general enough (abstract and open) such that it can be used in a wide variety of applications.
DF: Perhaps add note into definition for Protocol Modules saying that definition may be tightened up in the future, such that there is one handler associated with multiple blocks but this is TBD.
Noah: Certain headers may be declarative. Keep eye on fact that some things aren't processed but the information is there if necessary anywhere in the chain.
Comment: This is consistent with our current definition of handler that it is targeted according to any rules defined in the corresponding module which might include "anyone can get this".
DF: Hearing that people are comfortable with the current definitions of Block, Handler, Module.
Several: Agreement.
DF: Want agreement from WG that other definitions are okay.
David Clay: Question about Application and Processor definitions. Says all XMLP Handlers are encapsulated in XMLP Applications.
Henrik: Note, not in right hand column.
DF: Things not in the right hand column are not going to be published.
DF: Take it that we are in agreement that the right hand column is sufficient for the next publication of the glossary.
DF: Are diagrams in original glossary left unchanged?
Henrik: Abstract model figure 2.1 subsumes those. Figure 2.1 encapsulates all previous diagrams with one exception. One diagram shows blocks and how they are put into headers and bodies that is not represented in figure 2.1. Propose that figure 2.1 be include in replacement to some or all of the other figures.
DF: Proposal: accept figure 2.1 as part of glossary.
DF: Either go ahead with publication with revised terms and with original diagrams that are still consistent with the latest terms, or instead include updated figure 2.1.
Several: Latter option preferred.
Paul Denning: Might want to, additionally, show one block handled by 2 handlers, e.g., with intermediaries.
DF: We can update the diagram as we get a better handle on those issues.
DF: We will publish a new version of working draft of Requirements document with new revised definitions and with revised figure 2.1, which will supercede all diagrams except the one showing use of blocks in headers and bodies.
DF: Henrik, as document editor, can you do by end of week.
Henrik/Hugo: Agreed to submit document to publication team by end of day Friday.
-- Issue 44, JeffK report [9] -- Issue 41, Noah [7] -- RPC subgroup, RayW [8] -- Issue 47, DavidE [4]
DF: I took action item at last meeting to prioritize list of issues. Haven't been able to complete yet. Would like to know status of above actions to know how to prioritize them.
DF: Asks Erik talk to Issue 44 since Jeff is not present.
Erik: Jeff's proposal rejects putting transaction ids in the protocol binding. He offers two alternatives 1) include optional transaction id in Envelope or 2) Leave transaction ids as an application specific extension. Only response to proposal was from Jean-Jacques who stated that perhaps the transaction ids should be block specific rather than global to the entire envelope. Erik talked to Jeff about Jean-Jacques proposal and he felt that perhaps begging the question as to whether XMLP could recursively contain other Envelopes. That would handle the case that Jean-Jacques mentioned.
DF: To summarize, where we put the transaction id may be in envelope, app specific, or by block.
DF: Where is group on this issue?
Marwan: Agrees with Jean-Jacques. Why not have block specific transaction ids.
Noah: [Question about transaction ids.]
Glen: There is general confusion about the term transaction id. Intent is to correlate requests and responses.
DC: This came up at F2F. We should be using a different term such as correlation id.
Noah: We need to think about the range of message patterns that we will support. Is the notion of correlation id clear?
Glen: Yes. A correlation id is something that means something to the sender of the message so that when he gets any message back whether it be one or multiple…
Noah: Agrees that correlation id should be put into the envelope.
Question: Put in the envelope at the block level or the global level?
Noah: Put in headers when we can, but it can sometimes be clunky. Question as to what is the scope.
Comment: This is similar to a discussion that we had about message ids at the F2F.
Henrik: Because can mean something different to different applications we can't apply semantics to it. It is really just a place holder.
Vidur: The original context of this was RPCs. Within that context we have a need for a correlation id. This argues against pushing it into the application domain. At least within context of RPCs or RPC module we must allow for such a correlation id.
Henrik: We should consider using our own extensibility mechanism for this.
DF: Can we send back issue to Jeff to recast issue in terms of extensibility mechanism?
David Clay: Talk recently about using our own extensibility mechanisms ourselves to extend the protocol. Two questions: 1) Do we use the extensibility mechanism? 2) Do we include some extensions along with our specification?
DF: Does that speak to this issue.
DC: No. First we have to decide if we need correlation ids. If we do need them as part of the basic protocol then do we provide them via the extension mechanism or via the "envelope".
DF: So there is a separate decision to be made about whether we need correlation ids and how and if we use our extensibility mechanism.
[Discussion about correlation ids and their usefulness. The general sentiment was that we will need correlation ids and we should provide them through the extensibility mechanism.]
DF: Let's take this to e-mail.
DF: Asks Noah to brief us on Issue 41.
Noah: Originated by issue from Vidur. There is text in SOAP spec. that says to make a call the following is needed: URI of target object, method name, optional method signature, …". Spec. says SOAP relies on protocol binding for providing a mechanism to carry the URI; e.g., in HTTP the request URI indicates the resource that the invocation is being made against. Essence of Vidur's issue is that the target of the invocation is left to the protocol binding rather than something that you can see in the envelope and perhaps that's not the best way to do it.
Vidur: Yes that is correct. There is a difference between the identification of the target object and the address that the message is sent to. There should be a conceptual difference between the two.
Noah: Analysis summary: There is potentially a difference between the abstract place that the message is sent and the specific address where you send the thing (e.g., URI in HTTP). In many cases they could be the same. An application may know an abstract place that it is sending a request and lower level knows stuff like we know two ways to get there. Or we actually go through multiple transports to get there. This indicates that the application may prefer to deal with the address at a high level… Given this, do you want to specify the higher-level address in the envelope and do you want to specify the binding level address in the envelope. Propose that all headers including the body would have an actor with an explicit URI indicating the abstract destination.
Question: Is the issue one of a distinction of URNs and URLs?
Noah: We shouldn't require that the URIs in an actor be in the form of a URN as opposed to a URL.
John: In ebXML in the header we have symbolic information about the ultimate recipient. Inside TPA is where you put the actual target URL. That could be an intermediary that looks inside the message to figure out where to send it next.
Noah: You should not be required to rewrite the XML at that point to include the lower level address.
Henrik: Have problem going into URN/URI discussion...
Noah: I think we are agreeing
DF: Noah and Henrik need to come to agreement on this. Take to e-mail.
-- RPC subgroup, RayW [8]
-- Issue 47, DavidE [4]
DF: 2 other "AOB" items.
DF: Who will host F2F meeting in September?
Scott Isaacson: Novell could host in San Jose.
David Clay: Oracle could host in Portland.
Mark Hadley: (Sun) Still investigating.
Mark Nottingham: (Akamai) Still checking.
DF: Confirm by next week's teleconference.
DF: Second AOB item regarding Hotel block room nights for next F2F in France.
Noah: Room block only goes to night of the 6th. Can we get the room block extend to the 7th for the group?
Herve: Will look into it this week.
[1] http://www.w3.org/2000/xp/Group/1/02/21-minutes [2] http://www.w3.org/2000/xp/Group/1/03/GlossaryandTerms.html [3] http://www.w3.org/2000/xp/Group/Admin/#pending [4] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0010.html [5] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0006.html [6] http://www.w3.org/2000/xp/Group/xp-reqs-05#N2082 [7] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0014.html [8] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0005.html [9] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0027.html