I'll try and explain my original concern, although I'm pretty certain after reading your mail that it is actually of no concern. I was worried that someone could read the RP document while it was half-way through being written. I was thinking in terms of a chunk of memory being written by one thread, as another tries a read. But from what you say, i.e. that the results will be valid according to the schema, this is clearly not an issue. Given that updates to the component parts of an RP are atomic in some sense, I'm not aware of any coherence issues in the current WS-Agreement spec. Which is I guess what the comment from the telecon was saying also. Thanks for the clarification... Jon. On Mar 1, 2005, at 8:51 AM, Karl Czajkowski wrote:

I am not sure that I am following this concern, but to my knowledge WS-ResourceProperties does not define any coherency or consistency among resource properties. It only states that query results will be valid according to the schema. This is not about "writers" but about dynamic RP documents and the possible lack of synchronization in constructing the RP elements in query results. (WS-RF tries to be lenient about what infrastructure is required to implement the basic facilities.)

I think the best approach would be to define RPs that are meaningful in isolation from one another and only loosely associated with each other via their association to the resource identity; dynamic values that have temporal associations should probably be part of one RP element rather than spread across several. I do not think there is anything risky about stating that a particular RP will be updated coherently (coherence amongs its attributes and subelements).

A particular specification could add requirements, but of course this might restrict the WSRF tooling environments that are capable of hosting the standard. Also, I would be concerned if we required strong consistency and didn't make it so that a WS-Agreement environment would degrade gracefully if the consistency were violated; for example, references across terms could use temporally unique IDs for dynamic elements so that a consumer could detect a dangling reference rather than making an incorrect dereference. I suppose you could call this an implementation detail, but I would like to think we could encourage or even mandate some hygiene...

Can someone explain concisely what the consistency hazard is that has been raised?

karl

On Feb 28, Jon MacLaren loaded a tape reading:

...

...

Issue 13: The only thing that can change is the term states because there is no updates. So, there is no concern for consistency, and no need for consistent updates. **Action: Respond that we don't think this is a concern in the follow up. **Jim will add the comment to the tracker.

Just to clarify... I realise that no external parties able to update the monitoring information. However, the service/resource is changing state - is this state change any different from an external writer? I wasn't sure that WS-RF would guarantee the user sees a consistent state at these times - I thought you only needed one writer and one reader for consistency problems here.

Maybe someone who knows WS-RF better than me can clarify this.

Jon.

-- Karl Czajkowski karlcz@univa.com

Hi Karl, we should address the three issues in separate telecons for each after GGF13. I would have no problem to have a second comment period afterwards (where we should finally collect the positive comments after all ;-)) Best regards Wolfgang Karl Czajkowski wrote:

On Feb 28, Jim Pruyne loaded a tape reading:

...

All,

Here are minutes from today's telecon. We'll meet again next week at the usual time. Reminder to follow.

--- Jim

Sorry, I missed the call due to a nasty cold w/ fever...

Was there any discussion of the overall plan or scope of activity for the spec work? My gut feeling is that there were a number of minor points raised during the comment period but the three issues with the biggest practical impact are:

1) resolving the asynchronous/peer-to-peer messaging requirements

2) and making sense of the termination issue

3) understanding the Agreement lifecycle as it relates to these two problems

All of these have seen some discussion on the list, I know, but none have had a clear conclusion. My meta-question is whether we are in agreement that these should be addressed as possibly substantial edits to the specification (if necessary)... I think these problems overlap with some general specification "damage" which occurred when the negotiation mechanisms were stripped out and the state model reduced.

I think we should try to get these things right and be open to the possibility of a second comment period after the edits are complete.

Thoughts?

karl

p.s. of course there is also still a great need for a primer or other layman's guide, but I am focusing on the eventual standard itself.

-- Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258 Fax: +49 2241 14 42258 http://www.scai.fraunhofer.de "Heut ist nicht so kalt wie gestern, trotzdem dass heut kaelter ist"