RE: Issue #4: ref-integrity interoperabilityu

I like it.

--Judy

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Friday, February 26, 1999 2:24 PM
> To: 'Slein, Judith A'; Davis, Jim <jdavis@parc.xerox.com>; WEBDAV WG
> Subject: RE: Issue #4: ref-integrity interoperabilityu
> 
> 
> I will go you one better. Not only should the client be able 
> to discover
> what types of referential integrity the server supports but the answer
> should be properly scoped with the class of integrity. For example:
> 
> <d:supportedtypes>
> 	<d:referencetype>
> 	
> <d:referencetypename><m:xeroxintegrity/></d:referencetypename>
> 		<d:enforced/>
> 	</d:referencetype>
> </d:supportedtypes>
> 
> The client will only understand the "d" scoped elements. So 
> the client knows
> that the reference uses some sort of referential integrity which is
> identified by the m:xeroxintegrity element but has no idea 
> what the actual
> policy is. The client is then free to submit the URL which matches
> m:xeroxintegrity as an argument to the Ref-Integrity header 
> when creating
> the reference.
> 
> In this case the client is choosing to intentionally enter a
> non-interoperable situation. That is always their right. But 
> the protocol
> must be written so that entering this situation is a clear and obvious
> action. I believe that requiring the client to parse supportedtypes,
> referencetype, pull out the name from referentypename and match it to
> enforced more than adequately demonstrates that the client 
> really wants to
> shoot itself in the head.
> 
> 			Yaron
> 
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Friday, February 26, 1999 11:00 AM
> > To: Davis, Jim <jdavis@parc.xerox.com>; WEBDAV WG
> > Subject: RE: Issue #4: ref-integrity interoperabilityu
> > 
> > 
> > I'd like to emphasize again that this choice would make it 
> > for all practical
> > purposes impossible for a client to create a reference except with
> > Ref-Integrity: do-not-enforce.  The only references that 
> can really be
> > created would be ones for which the server promises *not* to enforce
> > referential integrity.  That seems to me unacceptable.  
> > 
> > I would be willing to go along with this *only if* we provide 
> > some way for
> > the client to discover what other values of Ref-Integrity a 
> > given server
> > understands.  We could do that with OPTIONS.  Then, even if 
> the client
> > doesn't understand what the acceptable values mean, it can 
> > just pick an
> > arbitrary one if it wants referential integrity enforced, 
> > assuming that
> > every value the server advertises will be some flavor of enforcing
> > referential integrity.  I think the most common case will be 
> > that the server
> > offers only one policy for enforcing referential integrity.
> > 
> > Then we can still hope that in the long run a common set of 
> > referential
> > integrity policies will emerge and be standardized, but in 
> > the short run
> > clients will be able to request referential integrity if they 
> > want it.  And
> > it will be possible for compliant servers to insist on 
> > enforcing referential
> > integrity.
> > 
> > --Judy
> > 
> > > -----Original Message-----
> > > From: Jim Davis [mailto:jdavis@parc.xerox.com]
> > > Sent: Friday, February 26, 1999 1:07 PM
> > > To: WEBDAV WG
> > > Subject: Re: Issue #4: ref-integrity interoperabilityu
> > > 
> > > 
> > > At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> > > >(Issue #4) Section 4.3.1 - ... I propose that the 
> > > Ref-Integrity header
> > > MUST be included in
> > > >all requests and that the only defined value be 
> > > DAV:do-not-enforce. A server
> > > >receiving this header with an unrecognized value MUST fail 
> > > the request. 
> > > 
> > > I agree.
> > > 
> > > No need to repeat his reasoning.
> > > 
> > > 
> > 
>

Received on Friday, 26 February 1999 14:55:53 UTC