- From: Dylan Barrell <dbarrell@opentext.ch>
- Date: Fri, 11 Jul 1997 03:34:35 -0400
- To: Dylan Barrell <dbarrell@opentext.ch>, "'-=jack=-'" <jack@twaxx.twaxx.com>, "'Judith Slein'" <slein@wrc.xerox.com>
- Cc: "jradoff@novalink.com" <jradoff@novalink.com>, "w3c-dist-auth@w3.org " <w3c-dist-auth@w3.org>
If the general consensus is that we should try to hammer-out the publish features then I agree that this would be the more elegant approach. Cheers Dylan ---------- From: -=jack=-[SMTP:jack@twaxx.twaxx.com] Sent: Mittwoch, 9. Juli 1997 12:47 To: 'Judith Slein'; Dylan Barrell Cc: jradoff@novalink.com; w3c-dist-auth@w3.org Subject: Re: Access Control Preliminary Draft The only time I can see it being necessary to disallow access to a resource is if its state is inconsistent due to dependent parts being out of sync (e.g. If an HTML page is edited and a reference to an image added and this image has not yet been posted to the server) ----------------- This is a good example. I am fairly sure, however, that there are others which may impose more rigorous requirements, but this is a good descriptive case. Your assessment of the possible solutions is exactly what I was hoping to see in terms of perverse boundary cases that impose the most stringent requirements on our functionality. In my case, the solution I would most likely select for this scenario is the "published version" approach. For example, even if a document contains multiple sub parts, I would not consider it "checked in" until all of it was checked in, so until all of the new revision is consistent, I would continue to serve the existing revision (which should already be consistent). There are authoring scenarios and/or working styles (for authors) that would make this difficult, however, and this kind of operability is, IMHO, the kind of thing we need to hammer out. For what it's worth, I think it's more clearly important to be able to lock a collection of resources (whether inherently related or not) for a wide variety of reasons, so I believe that feature is important in its own right, but certainly poses a potential solution to your scenario. I think it's likely that authors will want to make new revisions (or brand new content) of documents and in particular sets of documents available at once, so the ability to manage groups of locks in concert as well as the ability to manage the "published" state of groups of documents is likely pretty important, both of which relate to this functionality. Once this functionality is accepted, it's possible to use it in a variety of scenarios to support revision management. Also, I'll stake my opinion on supporting both styles of locks (i.e. those that prevent a resource from being accessed while locked and those that don't) particularly since at this point I am more concerned with an infrastructure that will support future as well as current needs as best as possible, and I can imagine that what is considered sufficient to support a facile interface to this functionality may well evolve over time. I could also see a solution that involves separating access from locks entirely, and simply allows the author to choose whether they want to change the access attributes while the content is locked on their own, which would allow them to make this decision... Whether or not these attributes (access vs. presence of locks) are linked is one question, but it's clear that we need to both be able to lock resources and to edit their access attributes, so the question would seem to be, should these two be automatically linked or should they be separate operations which may or may not be used together? -=jack=- (This text composed by voice) --
Received on Friday, 11 July 1997 03:37:38 UTC