[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Primer (was RE: [ws-caf] bug 135 - participating services list)
Peter, from memory this was discussed a few times, particularly at the very start of the lifetime of the TC and I think we agreed to revise those parts of the Primer as and when the relevant specification was finalised. Mark. >===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> ===== >Mark, Eric, > >You both mentioned revising the Primer as part of the solution on this. >Is >there a schedule for revising the Primer ? Is it going to be done >piece-meal >(i.e. revise the ws-context bits soon, the other parts later) or will it >wait until the normative documents are all done ? > >Should we be reviewing the Primer's ws-context sections for discussion >at >the face-to-face ? > >Peter > >> -----Original Message----- >> From: Mark Little [mailto:Mark.Little@arjuna.com] >> Sent: 30 June 2004 05:21 >> To: Furniss, Peter; Newcomer, Eric; >> ws-caf@lists.oasis-open.org; Mark Little >> Subject: RE: [ws-caf] bug 135 - participating services list >> >> >> Peter, I don't think being facetious will get you very far. >> The email from >> Eric was correct IMO. There are several companies within this >> TC that are >> actually interested in doing implementations of WS-Context >> and WS-CAF in a >> timely manner, IONA being one of them. >> >> My point (based on the back of Eric's email and apparently >> entirely missed by >> you) was that as Eric says, appropriate text can be added to >> the current >> specification and Primer. >> >> Now, we could spend years making sure we have a "perfect" >> specification, but >> meanwhile the real world moves on and things that live >> entirely within >> standardisation efforts become less relevant as a result. >> There are many cases >> in point for this, and you should be able to speak to this >> from personal >> experience too. >> >> Mark. >> >> >===== Original Message From "Furniss, Peter" >> ><Peter.Furniss@choreology.com> >> ===== >> ><irony> >> >Let's fill it up with lots of optional fields that might be >> useful to >> >higher protocols if they choose to define the mechanisms to >> make them >> >functional. We could have user identifications, security fields, >> >database strings (see the use-case/examples discussion from the >> >beginning of the tc). >> > >> >They'll all be optional, so they won't represent a problem >> to the spec. >> ></irony> >> > >> >Putting in or leaving in random fields because they seemed >> like a good >> >idea at one time is no way to produce a good spec. >> > >> >If anyone thinks it should stay, let's see the "appropriate >> text" that >> >fully defines what participants MUST do so other services can find a >> >list of participating services that actually includes the >> participating >> >services. It was when I did that I became convinced it was >> a mistake >> >and neither the mechanism or the field belonged in the spec. >> > >> >And, in passing, "at this stage in ws-context" is first review of >> >radically re-written and cleaned-up spec. It wasn't possible to >> >consider the details of the fields of the context itself >> until the als >> >stuff had been sorted out. >> > >> >Peter >> > >> >> -----Original Message----- >> >> From: Mark Little [mailto:Mark.Little@arjuna.com] >> >> Sent: 29 June 2004 23:45 >> >> To: Furniss, Peter; Newcomer, Eric; ws-caf@lists.oasis-open.org >> >> Subject: RE: [ws-caf] bug 135 - participating services list >> >> >> >> >> >> At this stage in WS-Context I have to agree. I don't see >> the harm in >> >> leaving in an optional element. We can add some >> appropriate text to >> >> the spec. to ensure that the field is documented, and >> perhaps enhance >> >> the primer. >> >> >> >> Mark. >> >> >> >> >===== Original Message From "Newcomer, Eric" >> >> <Eric.Newcomer@iona.com> >> >> >===== Peter, >> >> > >> >> >No, I disagree. It can be easily defined, that is, as a >> reference >> >> >point for >> >> other services to find the list of other participating >> services. It >> >> is an optional element in any case and therefore does not >> represent a >> >> problem in the spec. >> >> > >> >> >Eric >> >> > >> >> >-----Original Message----- >> >> >From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] >> >> >Sent: Tuesday, June 29, 2004 12:56 PM >> >> >To: ws-caf@lists.oasis-open.org >> >> >Subject: [ws-caf] bug 135 - participating services list >> >> > >> >> > >> >> >I would like to formally propose, as a resolution of bug >> >> 135, that the >> >> participating-services-list element be removed from the WS-Context >> >> document and schema. >> >> > >> >> >http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=135 >> >> > >> >> >As I think the discussion on this has shown, appreciable >> additional >> >> specification is required to make it work, and that specification >> >> would want to constrain the general flexibility of ws-context. It >> >> should therefore be considered as a candidate for a "referencing >> >> specification", and not part of >> >> the base ws-context. >> >> > >> >> > >> >> >Peter >> >> > >> >> >------------------------------------------ >> >> >Peter Furniss >> >> >Chief Scientist, Choreology Ltd >> >> >web: http://www.choreology.com <http://www.choreology.com/> >> >> >email: peter.furniss@choreology.com >> >> >phone: +44 870 739 0066 >> >> >mobile: +44 7951 536168 >> >> >> >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]