OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes from f2f 7-12-2004 afternoon



WS-CAF Minutes: 7/12/04 1:00PM PST

Martin: recap of morning session.

Martin: Brian Murray [see .04 draft of WSCTX.doc] section 2.2] made a comment about the wsctx wsdl only being partially normative.  The current context wsdl only mentions one-way messages.  Is that Normative?

Mark: In New Orleans we decided that the one-way messages would be normative and request-response would be for  a later version.

Martin: The spec should say “primarily uses one-way messages with callbacks”.

Greg Pavlik: Not primarily, but entirely... all the messages, operations and bindings are one-way style.

Martin: The specs should say “one-way operations with callbacks”.  This is prescriptive.  Other binding styles are possible, although they may have different acknowledgment styles and delivery mechanisms.

Martin: [section 1.3 of WSCTX.doc version 0.4] see comment mcl4-mcl6. Check with Greg who wrote this paragraph.

Greg: Figure numbers are incorrect... for example Figure 2 should be Figure 3.  The text that includes mcl4 should actually be a figure – figure 2.  Make sure the example is a coherent unit of text.

Martin: [reads mcl7 of WSCTX.doc version 0.4]  Regarding addressing spec.

Greg: [points to section 2.3] the spec intentionally does not specify how to do callbacks.

Martin: The spec needs to mention what assumptions are to be made with regards to addressing.

Martin: [reads mcl8 of WSCTX.doc version 0.4] who objected to this?

Mark: unique is unique... no need for “globally unique”.  

Eric: It's not necessary to say “globally unique”.

Martin: Votes to remove the phrase.

Doug: It's not the scope of uniqueness it's the scope of this particular id.

Martin: [clarifying Doug's point] the id's only needs to be unique in time?  Meaning it can be reused.

Greg: Uses a bank analogy to explain problems with reusing a unique id in any given time frame.  Ex.  The transaction id in a bank transaction should never really be reused.

Martin: Add a footnote or leave it.

Mark: Leave it.

[Vote: getting rid of “it must be globally unique”.  Result: carried (5 for, 1 abstain)]

Martin: [reads mcl10] If there are ordering dependencies they should be part of the description of the operations.  Action: Where an operation has dependencies, ex., a complete operation depending on a begin operation, it should be described in the spec.

Martin: [after some discussion] The behavior is undefined.  The client is free to do whatever it wants to do.  Action to the editors: put text into section 2.3 for unsolicited responses.

Martin: [reads mcl12]

Mark: This is addressed by the assumptions we addressed earlier in regards to reply-to.

Martin: Changing the context part of the primer.  Once we get the committee draft of the context spec we will change that section of the primer.

Doug Bunting: Explains problems currently experienced by WSRM's ServiceRefType.  WSRM wishes to add a bare uri element that is basically a fall-back that does not rely on any specific addressing specification.

Martin: Should our specs refer to the WSRM type (for ServiceRefType – see wsctx.xsd)?  The benefits would be that we wouldn't need to redefine the type.

Greg: But the base uri needed by wsrm is only needed for reliability semantics?

Doug: No.

Martin: Are we going to reference what WSRM is doing?

[discussion on the semantics of adding a bareUri element to ServiceRefType]

Martin: Revisit this for Aug 2nd conf call.

Martin: [section 5.2, 2nd sentence] “A begin can be modeled as the first Web service in the Activity to register itself.” 
Alistair: should be changed “A begin is therefore the first operation in an activity to use ws-context”.

[discussion of whether an activity is properly defined by the spec]




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]