RE: [ws-caf] bug 135 - participating services list

["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
> >>
> >>
> >>
> 
> 
>