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


Title: Message
Peter,
 
You are arguing that we should change something in the current spec because we don't know yet what the referencing specs will do with it.  That is an argument to wait and see what impact, if any, the referencing spec(s) will have on the current spec.  Certainly when we start on the changes for WS-CF and WS-TXM we can revisit this question and at that time if a change is necessary to WS-Context then we can make it at that time, and be sure what it needs to be rather than guessing, which we are basically having to do now.
 
So - can we agree to revisit this when we are starting work on the referencing specs rather than trying to anticipate the situation?
 
Thanks,
 
Eric
-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Tuesday, June 29, 2004 7:58 PM
To: Newcomer, Eric; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

It's not that difficult to define the concept in a hand-waving sort of way. But, as I hope I've made clear in the long messages I sent last week, it isn't a a reference point for anything unless there is a significant and mandatory protocol to maintain it. Information about which services are "participating" won't ooze into a single place by magic. It requires ALL the participating services to do their bit to register their participation (or all the invokers of all the services, which might or might not be simpler and would give a distinctly different semantic).
 
You've suggested that we discuss some lightweight sharing mechanism to handle this (I'm still not certain that is what you were talking about). I've put in two longish messages outlining possible mechanisms, which have various problems. Could you give some more details on how you think this will work ?
 
Or are you suggesting that we should keep a field in ws-context which is "sort of a participating services list", with no clear semantics ?  If a referencing specifcation is defined that gives it a well-defined meaning, that specification can put the field in an extension - it has no business in the base schema, any more than other fields whose semantics are defined by referencing specifications.
 
Hand-waving "specification" may work within a closed community, or between instances of the same implementation - informal communication between the programmers can deliver distributed communication sufficiently. But with supposedly interoperable specs an enormously greater level of detail has to be provided. You cannot just trust the other side to understand what you thought - you have to nail done the required behaviour of all the systems so their implementors know precisely what they must do and what they can expect others to do.
 
Peter
 
 
-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: 29 June 2004 23:39
To: Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

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