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: Primer (was RE: [ws-caf] bug 135 - participating services list)


Mark, Eric,

You both mentioned revising the Primer as part of the solution on this.
Is
there a schedule for revising the Primer ? Is it going to be done
piece-meal 
(i.e. revise the ws-context bits soon, the other parts later) or will it
wait until the normative documents are all done ?

Should we be reviewing the Primer's ws-context sections for discussion
at
the face-to-face ?

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]