Re: Comments on 06 spec

   Jim/Judith,


    I am little bit confused with COPY, MOVE and DELETE operations. 

    I have gone through the scenarios document, and protocol document. I
would appreciate if someone can explain to me
    how the following scenarios are handled using the current protocol spec.
I am not trying to take whole group
    back to use case analysis stage, but, my objective here is to make sure
that current protocol has all definitions and
    explanations to have a clean implementation. Otherwise, to overcome some
of the limitation each implementor will choose
   their own way of interpretion and which lead to interoperability issues.

    Scenario A:	Jane directs that the page P and all subordinate objects be
deleted from the web W.
		Joe directs his web browser to retrieve page P from the web W.

		Issue here is: If deletion of page P and associated subordinate objects
from the Web W
		takes sometime to process, then Joe requests this page and by that time
some references
		to that page might have deleted already and hence joe sees broken links on
page P. This throws an
		integrity issue.  Or in other case, assume joe had already started editing
this page P. Jane deleted
		this and when joe gets into publishing stage there is no matching
properties associated with the same
		document. 

   Scenario B:     Jane directs that collection C be moved to collection D.
While this move
		operation in progress. joe directs his editor to take a write(exclusive)
lock on Collection D.
		This request will succeed as MOVE operation hasn't taken any explicit lock
on Collection D.
		If this assumption is right, then, rest of the move operation will fail as
EXCLUSIVE WRITE lock has acquired
		by joe on collection D and jane cannot be completed either server will be
WAITING for lock release
		on collection D.

   I think, to make the spec more clearer, good add some more explanation on
COPY, MOVE and DELETE methods, how
   locks are issued on source and target resources for these operations and
impact of this on relevant methods.

   Regards,
   -Surendra

  ------------------------------------------------------ 	
Surendra K Reddy         Tel.   +1(650) 506-5441 
                         Fax.   +1(650) 506-7421
                         Email.	skreddy@us.oracle.com
"It is unwise to be too sure of one's own wisdom. It is healthy to be
reminded
 that the strongest might weaken and the wisest might err."  

  
Warning: Statements and opinions stated herein may not be those of Oracle
Corp.
  

attached mail follows:

Yes, you are right about the definition of link.  Keep it the way it is.

At 12:35 PM 1/23/98 PST, Jim Whitehead wrote:
>>
>> I also wonder if the formal definition of link is right.  It says:
>> <!ELEMENT link (src+, dst+)>
>> But the accompanying text says you are trying to allow for multiple links
>> of the same type on the same resource, so do you really mean:
>> <!ELEMENT link (src, dst)+>
>> Or are you trying to allow a single link to have multiple sources or
>> multiple destinations? Or both, perhaps:
>> <!ELEMENT link (src+, dst+)+>
>
>Hmm.
>
>Right now we use the link element in the source property, which is defined:
>
><!ELEMENT source (link)* >
>
>Combined with the definition of link:
>
><!ELEMENT link (src+, dst+)>
>
>This allows the source property to contain multiple links, each of which 
>can have multiple sources and multiple destinations, as is shown in the 
>example in Section 12.11.1.  It seems that there is a slight advantage to 
>keeping the definition of link singular (i.e., only one single link) since 
>this way you can specify a property to only include a single link.  If link 
>was defined like:
>
><!ELEMENT link (src+, dst+)*>
>
>It would be impossible to specify only a single link without creating a new 
>production.
>
>So, my inclination is to leave the specification as-is. Do you agree?
>