Actually, Martin, I think we're more or less on the same page.
My initial point was simply that "last saved" is a description of a
revision, and so belongs under revision description, whereas creationApp
is supposed to be a record of tools used. So I see creationApp as being
akin to langDesc (if that's what it was called) or characterDesc in P4
(something that might offer a model, BTW). Adding a date to creationApp
seems to me likely to imply that the actual date was in someway
intellectually important. As a result, I can easily see how people might
want to record multiple uses of the same tool for different purposes
under creationApp, leading to the presentation of material that more
properly belongs in revisionDesc. In otherwords, "last saved" if at all
important, is really part and parcel of a revision (you wouldn't save if
nothing was done), rather than an intrinsic feature of the apparatus.
That people don't make good revisionDesc on the whole doesn't seem to me
to be an argument for moving it here. It seems simple enough to require
a date be placed in revisionDesc containing information about the tool
(i.e. the ID referring to the right element in creationApp), the
operator (the person intellectually responsible), and date and nature of
the revision (even if this is just "saved").
However, while unhappy about it philosophically, I can see that
recording the last date on which a tool was used in creationApp might be
easier and that the date saved would be useful for debugging. So while
the purist in me wants to see only information about the actual tools
itself in creationApp, and information about actual dates and actions
saved in revisionDesc, I'm not one to get in the way of progress, if
that's what others want.
I think the idea of a creationApp is an excellent idea. But like I said,
I think the best model may be the old langDesc.
On Tue, 2006-30-05 at 09:42 -0700, Martin Holmes wrote:
> I think we're at cross-purposes here: I'm not intending that the
> application should add anything to the revision statement. I think the
> revision statement should be entirely in the hands of the user, who can
> edit it as they see fit, either inside or outside the application
> itself. The application would simply add a single creatorApp tag, or if
> one already exists for its appID, it should modify the existing one; and
> the creatorApp tag should include a date when the file was last saved by
> the application. I'm not sure how that differs from a "last used" date;
> basically I'm assuming that whenever the application saves a file, it
> will put the date and time of the save into that creatorApp/date tag. If
> the same app is used repeatedly, the same tag would be overwritten each
> time with a new date/time.
> Or am I misunderstanding you?
> Dan O'Donnell wrote:
> > It's a minor point. Perhaps in that case having a lastused date rather
> > than anything else? That still provides debugging information, but
> > doesn't create the temptation to build a second revision statement if
> > the same tool is being used repeatedly.
> > -d
> > On Tue, 2006-30-05 at 05:12 -0700, Martin Holmes wrote:
> >> Hi there,
> >> I take your point, but I think the application should be able to store
> >> information it (and other applications) can use. A user may not bother
> >> to add revision information; it may not be important from an
> >> intellectual point of view when the app last saved the file, but it
> >> could be important to the application if it's trying to disentangle
> >> corruptions or conflicts. I think it's reasonable to privilege the last
> >> usage because that was the last successful editing session (presumably).
> >> Cheers,
> >> Martin
> >> Daniel O'Donnell wrote:
> >>> On Mon, 2006-29-05 at 12:57 -0700, Martin Holmes wrote:
> >>> Good enough. But then perhaps last saved doesn't belong here either?
> >>> I.e. It sounds like this is a storage for information about machines
> >>> rather than actions. Last saved would also be recoverable from the
> >>> revision history (or the file date). And including it implies that the
> >>> tool was used that once... or at least it privileges the last usage.
> >>> Perhaps this is really like the old Language declarations.
> >>>> My gut feeling is that this would be overkill. The app itself can only
> >>>> know when it saved the file; it can't really know what the user's
> >>>> purpose was in working on the file that day. The user does know that
> >>>> info, and if it's important, it can go into the teiHeader in the usual
> >>>> way as part of the revision description; in the IMT, you can edit the
> >>>> teiHeader as text inside the program, and I think most tools would allow
> >>>> this sort of thing. "Last saved date" is a mechanical thing, whereas
> >>>> revision descriptions are intellectual content best left to humans. If
> >>>> each app which worked on a file left its "last saved" date in its
> >>>> creatorApp tag, an app such as IMT might be able to provide useful
> >>>> diagnostic feedback in the event of (say) failure to open a file --
> >>>> something like this:
> >>>> "Since this file was last opened in the Image Markup Tool (25/05/06), it
> >>>> has been edited using Joe's Universal TEI Editor (27/05/06), at which
> >>>> time key data relating to annotation categories appears to have been
> >>>> deleted. The Image Markup Tool is no longer able to open this file
> >>>> normally. Would you like to attempt reconstruction of the missing data?"
> >>>> (Not that my app has anything that clever in it at the moment ;-) But if
> >>>> we had a standardized creatorApp module, that sort of thing would be
> >>>> possible.)
> >>>> Cheers,
> >>>> Martin
Daniel Paul O'Donnell, PhD
Acting Chair and Associate Professor of English
Director, Digital Medievalist Project
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 (403) 329-2378/-2377
Fax: +1 (403) 382-7191