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