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:23:49 UTC