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

[Mark Little <Mark.Little@arjuna.com>]

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