OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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