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


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]