Corrected minutes for 27 March 2006

wsn message

WS-Notification TC Minutes, 27 March 2006

TOPIC: EVM Roadmap

William: Describes roadmap (links are in agenda). Powerpoint slides are unofficial, main document is approved by the four participating companies.

Ed. Note: The discussion here follows the coloring in William's slides. "Blue" is WSDM, WSRF, WSN etc., (i.e., the OASIS specs), "Yellow" is WS-Management, WS-Eventing, WS-Enumeration, WS-Transfer etc., and "Green" is the proposed harmonized specs. Indented material was typed into the chat directly.

Peter: Concepts are pretty close. E.g., subscription modeled as resource, with lifetime etc. All will be clearly visible in new spec.

Fred: From implementor's view, basic concepts are fine, but doesn't really change much. This doesn't mention topics or subjects.

Peter: Base specs (enum, transfer, eventing) haven't changed. Adding new layers on top, not rev'ing existing specs.

Jamie: The items on the lower right (WS-Management stack). Those three are notes?

Jamie: Your last slide whites out everything below. Do the present specs go away?

William: No. New stuff depends on them. Old stuff fades out, but some are copied in new specs. The graphic has a mistake.

William: They can still be used. The last slide just shows what is the convergence.

Peter http://devresource.hp.com/drc/specifications/wsm/index.jsp The existing functionality of WS-Notification not explicitly defined in WS-EventNotification can still be layered over its message model and functionality as an extension.

Peter: At this point, should look at the actual roadmap doc. Figure 2 shows EventNotification and Notification. In particular, text (pasted in) refers to Notification as being supported.

IBM and others will continue to support WS-Notification, and expect to work in standards to better integrate the WS-Notification specifications with WS-ResourceTransfer and WS-EventNotification. Programmers can use the more advanced functions of the WS-Notification framework when necessary.

IBM and partners will ensure that implementations that use WS-Notification will work in environments with WS-EventNotification and WS-ResourceTransfer.

Jamie: Graphical overview is very useful, but we would like to know what IBM thinks will happen to WSDM, especially in terms of tooling. My takeaway is that we will abandon the XML codebase of the blue stuff (WSN etc.) and move to the green codebase, using the concepts from the blue but the XML from the yellow (Eventing etc.)

Jamie: Committee will have to work with what's in EventNotification (which is not public)?

Jamie: There would be workshops, interops etc. questions of tooling, all sometime down the road. Can't norm to something that doesn't yet exist.

Jamie: Or all the pieces already present? Are the deltas (e.g. from WSE to EventNotification) small enough that you could work from WSE?

William (for himself, not HP): Don't think it's small, but it's based on WSE and the roadmap, which are not changing. You can at least see where there is risk of overlap etc. Roadmap, e.g., says nothing about brokering.

William: Yes. What I meant by graying out in slide was to separate what's in roadmap from what's not.

Ian: Those of us coming from OASIS side are keen to have people understand that OASIS technologies will continue to go forward and exist. The roadmap just states that the companies that have invested in both technologies will need a middle ground so that the two stacks can talk to one another.

Jamie: My understanding that after changes WS-Enumeration, Transfer, Eventing were going to be proposed for continuous use along with the green stuff, but not the blue stuff. Is that correct?

Ian: No. There are operations defined in WS-Transfer that won't be able to support operations intended for ResourceTransfer. E.g. if you were to do a Get operation with WS-T, that would get an entire resource. If you want a smaller part, WS-T won't, but WS-RT and WS-RF do. You can still use WS-T Get. E.g., WS-RF defines (some attribute). That attribute might not be defined in WS-RT, but you can continue to use it with WS-RF. There will be aspects of all existing specs that won't find their way into merged specs, but will continue to be used.

Peter see sentence from the roadmap
Peter IBM and partners will ensure that implementations that use WS-Notification will work in environments with WS-EventNotification and WS-ResourceTransfer.

Ian: E.g. ResourceProperty attr will still be defined, but resources may also support WS-RT operations.

DaveS: The XML code base represented in WS-RF will continue to exist along side, right? We don't know what happens in the market in the two-three years before merge becomes standardized. All three sets will exist for some time to come.

Jamie: Thinking at "elevator pitch" level. What will replace what? What do the proposers of this merge think WSN should do. William seems to suggest harmonization down the road (also consistent with what DaveS says). But what should we do now?

William: The four companies don't have a recommendation to WSN. IBM and HP might have some input.

Jamie: (and that includes committee chairs and others). Not expecting definitive statement.

Ian: IBM's recommendation is that this is a piece of work that the 4 authors are planning on spec-ing out over extended time. Recommendation is for TC's to continue chartered work, and just be aware of roadmap. Do not want TCs' work (of last four years) to be derailed.

Fred: Still curious what that means exactly. Not going to toss out existing works. But when four reasonably powerful companies say "we're working on this, and it supplants work of TC's"

Ian (for IBM): IBM has a long (arguably slow) product lifecycle. We will ship support for WS-RF and WSN this year, irrespective of harmonization. Harmonization is our attempt to listen to IBM customers who don't see us involved in WS-T, etc. This is medium-to-long future. Derailing WS-RF and WSN would not be in our interest.

Jamie Clark Jamie notes (with gratitude) that the notetaker is valiantly trying to catch the flavor of this chat -- but not all of his paraphrases reflect what an individual has said. I didn't mention "any reasonably powerful companies", for example. Nothing personal, though: notetaking of this kind is very difficult on the fly.

DHull (Please feel free to make corrections. I'm not catching all of this.)

Sanjay: Assuming that you would presently support WSRF etc., later harmonized specs, would this be backward compatible.

Peter: Impl might support, e.g. multiple spellings of "Subscribe"

Fred: Certainly possible, but we have standards groups exactly to avoid this sort of thing. It's an interesting question what should TC's do. Time frame is 1 yr. 18 mo.

Jamie: It's important to note that at its very best, this roadmap represents an intent to do something. Assumes successful workshops, etc. I'm always touched to see a vendor express that it thinks something can happen in a standards body in 18 months. There are several steps on critical path for what occurs in paper to actually happen. Can't assume it will actually happen. Lots of intermediate steps.

Peter: Can discuss this at length. Can we agree to progress as quickly as possible to Committee Spec?

Paul: Migration of concepts into new specs is interesting. Intent to migrate most useful concepts. Probably beyond scope but: OASIS stack is intertwined, e.g. WSDM-MOWS is missing, but this was an important enough abstraction to have its own document. Can you briefly overview where that goes.

William: MOWS doesn't show up in roadmap. WSDM really means WSDM-MUWS. Roadmap stuff isn't really relevant to MOWS.

Peter: Obviously have to monitor this. Limit to what we can do in any case. Propose that we continue with PR revision and get to Committee Spec ASAP. Is there any objection to this?

DaveS: Strongly against stopping either WSRF, WSN or WSDM. Having a clear picture of the standards, and impl/user experience is very useful to harmonization. Wouldn't expect official result of harmonization before three years. WSRF will not sit around for this, neither should WSN.

TOPIC: Votes for WSRF.

DaveS: WSRF is about to become member spec. Still a handful of votes shy, four days left. Getting 15% of OASIS to vote (at all) is a challenge. In the interest of supporting the process, please ask primary members to vote (preferably yes . URL for vote is in mail I sent. It shows status, so you can see if you've voted (some members of TC haven't).

TOPIC: New issues?

Peter: Only one I saw was that WSA is in PR. Don't believe we have to change anything. Reference is OK. Namespace hasn't changed.

TOPIC: Status of main specs

Peter: BaseN. Have new working draft, DHull reviewed by me. Outstanding issues and errata are resolved/executed. Spec is ready for final public review. Will leave on website two-three days. Please check through and let us know. Ballot will be for last part of this week early next week. Any objections?

Peter: Brokered. Still needs errata reference, but otherewise good as well. Will do the same as for BaseN (web-site, ballot).

Peter: WS-Topics. There are a number of errata. Have discussed one, the rest are RFC 2119 things. Will post document, please have a look. Peter //tns2:B Peter as opposed to tns2:B

Peter: Only real outstanding issue is 4.29. Wanted to clarify consensus. Issue is that there are multiple ways of getting at extension topics. E.g. B extends A. Want access as B as well as A/B. Consensus now is that this complicates things, so we now allow A/B (actually ns1:A/ns2:B). For simpler access, allow // as //ns2:B.

Peter: Current approach: Force topic B to be present in both places. Proposed is as above. Second proposal is to allow B but pre-process in //. (i.e. "tns2:B" is syntactic sugar for "//tns2:B" if tns2 is an extension)

Peter: My AI was to look at second and third. I will put up variant versions with these approaches, but that will take 2 wks to progress. Would like to progress further than that. Any suggestions?

Peter: Will look into syntactic sugar approach, using "can you spec it?" as benchmark. If it works cleanly, will recommend it. If it's a dog's breakfast, will go back to second approch (explicit //).