[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Primer (was RE: [ws-caf] bug 135 - participating services list)
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]