[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] bug 135 - participating services list
Peter, two things: (i) we have both worked on many standardisation efforts, often with some cross-over, and in all cases I can think (from BTP to OTS) there have been cases where issues have been punted to the "next" revision in order to ensure that the specification can be released. I consider several issues on the current list as simply not being that harmful to ignore for the 1.0 specification. This is one of them. (ii) I believe this is really Eric's issue, so providing text is not something I would be working on. But as a member of the TC I'd certainly review it, as I'm sure you will. Mark. >===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> ===== >I probably shouldn't have given in to the temptation, but it I >find it hard take seriously the suggestion >that because a field is optional it doesn't matter if there is no >well-defined meaning for it. > >I didn't miss Eric's suggestion of putting in appropriate text. As >I've said in every messasge in this sequence, I don't think it >is a just a sentence or two and it must place mandatory requirements >on implementations. I worked out, and sent to this list, >suggestions for the type and quantity of specification needed. Eric >has suggested we have a discussion on a specification to be >external to ws-context (or at least the body of that). There has >been no other suggestion of text that would define participating- >service-list effectively. > >So > >a) are you asserting that it is ok to have junk fields in context >provided they are optional > >b) do you have text, in outline at least, to go in ws-context to >make maintenance of the p-s-list work > >c) should we delay ws-context while the mechanism to maintain p-s-list >is reviewed and checked > >If there are several companies actually pursuing implemenation of >ws-context, they ought to have designs for how p-s-list works (and >for the child-context questions. and for propagation. and for >reference/value >switching) Do they think these should remain proprietary ? > >The thing that delays specs beyond their useful date (and yes, I do have >more experience of this than I'd like) is adding things that have >doubtful utility or leaving in half-formed functionality that hasn't >been worked out. > >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]