RE: File creation date, version creation date, and getlastmodified

Hmm, not sure why this message was caught by the spam filter; for some
reason Lisa was bumped from the list.  I've added lisa@xythos.com to the
accept2 list -- Lisa,let me know if I should re-add you to the list as well.

- Jim

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, May 09, 2001 9:38 AM
To: Dan Brotsky; Sridhar Erukulla
Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org
Subject: [Moderator Action] RE: File creation date, version creation
date, and getlastmodified


This sounds so similar to the "structured documents" that were discussed on
this list ages ago.  As I recall, one of the scenarios for having a resource
that was a cross between a collection and a document was to gather a web
page together with its images in one place.  In some ways, it's treated like
a single document -- the browsing client should just see the resultant web
page when they try to view the resource.

Yaron's brief proposal:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0220.html
Judith's elaboration:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0239.html
Jim's issues and clarifications:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0301.html

The draft "draft-hopmann-collection-props-00.txt" had a property related to
this, "isstructureddocument".  I replied to some questions about the intent
of this property:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0028.html

I'm not at all sure that the model that would work for web pages (which have
multiple independent pieces) would work for your assets, but it's possible
that some of the same mechanisms could apply.  I think there is some common
ground:

 - A casually browsing client usually needs to see a "structured document"
or "asset" as a single resource, with a dominant view.  They may not need to
understand anything about the interior structure.
 - When dealing with casually browsing clients or old clients, the server
can pretend that the resource is a simple resource with a content-type of
html, ms-word, pdf or whatever the content-type of the "default" document
inside the container is.
 - An advanced client may need to break open the container to examine or
deal with the pieces, but probably not all the time.  E.g. the container
would be broken open when editing or changing structure (e.g. deleting
pieces, deleting old versions).
 - While the contents of the container may be versioned, the container
itself may not be (unclear).

lisa


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Dan Brotsky
> Sent: Thursday, May 03, 2001 11:20 AM
> To: Sridhar Erukulla
> Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org
> Subject: RE: File creation date, version creation date, and
> getlastmodified
>
>
> At 1:03 PM -0400 5/3/01, Sridhar Erukulla wrote:
> >In our document management system we have two concepts, 'Object'
> >and 'Document'. An 'Object' comprises of a 'Document' and all its
> >properties. The function GetLastModified for a document retrieves
> >when the actual document was modified where as for an object when
> >the object was modified which includes the properties and
> >document.
> >
> >We found that this distinction was critical in distinguishing the
> >physical actions like library maintenance, caching etc. vs. the
> >business operations like using workflow.
>
> Adobe's InScope server does a similar thing distinguishing "Assets"
> from "Versions" (which are the content and dead property snapshots of
> the asset); assets as a resource have content and properties (the
> latest version) but also properties that the version doesn't have.
> Many of these "non-content" properties are about the workflow.
>
> Our approach (prior to delta-V) has been to establish a conventional
> relationship between the asset URLs and the version URLs; in fact
> assets are (non-DAV-compliant) collections of their versions.
>
> With delta-V stabilizing we are hoping, going forward, to use delta-V
> mechanisms to connect assets and their versions.
>
>      dan
> --
> Daniel Brotsky, Adobe Systems
> tel 408-536-4150, pager 877-704-4062
> 2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Wednesday, 9 May 2001 12:47:05 UTC