Print

Print


On Mon, 2006-29-05 at 11:54 -0700, Martin Holmes wrote:
> HI Dan,
> Dan O'Donnell wrote:
<snip/>
> > If you are considering that one or more <creatorApp> could appear in
> > <respStmt>, then let me suggest putting the appID as an att value on
> > creatorApp at the very least.
> 
> That makes sense. So it would then look like this:
> 
> <creatorApp appId="ImageMarkupTool1">
>       <appIdent key="appName">Image Markup Tool</ident>
>       <appIdent key="appVersion">1.0.3.5</appIdent>
>       <appIdent key="appURI">http://..../</appIdent>
>       <appIdent key="userDefined" userKey="licence">Mozilla Public 
> Licence 1.1</appIdent>
>       <date value="2006-05-25T11:03:55">Last save: 2006-05-25 at
>   11:03:55</date>
>   </creatorApp>

Another suggestion: what about that date value? a) I might want to keep
track of revisions produced by this instrument (or at least dates), and
b) there might be multiple stages in using it: e.g. coding done this
day, image to coding done that day, notes done the next, etc. Should
there by a type (or purpose if your church doesn't like type on
everything) on date? I'd do something like this (using pseudo TEI rather
than checking if date allows this yet):

<date type="lastSaved">20060525:110355</date>

I realise this is getting very close to revision statements. One other
solution to handle this might be to take advantage of that id number on
<creatorApp> and cross reference it with revision statement in a feature
structurish way. Then you could get rid of date here and have multiple
instances of creationApp for each distinct process, even if it were by
the same tool.

-d
> 
> Cheers,
> Martin
> 
> > -d
> > 
> > 
> > 
> > On Mon, 2006-29-05 at 09:11 -0700, Martin Holmes wrote:
> > 
> >> <creatorApp>
> >>     <appIdent key="appId">ImageMarkupTool1</ident>
> >>     <appIdent key="appName">Image Markup Tool</ident>
> >>     <appIdent key="appVersion">1.0.3.5</appIdent>
> >>     <appIdent key="appURI">http://..../</appIdent>
> >>     <appIdent key="userDefined" userKey="licence">Mozilla Public Licence
> >> 1.1</appIdent>
> >>     <date value="2006-05-25T11:03:55">Last save: 2006-05-25 at
> >> 11:03:55</date>
> >> </creatorApp>
> >>
> >> This would involve only two new tags, <creatorApp> and <appIdent>, and 
> >> two attributes, "key" (an enumeration) and "userKey" (a string). Lou's 
> >> suggestion that it belongs in encodingDesc is surely correct. I've 
> >> included below the more detailed explanation from my message last week. 
> >> Before I submit this as a feature request on the sourceforge site, I'd 
> >> like a little more feedback (especially from other people involved with 
> >> creating TEI tools). Any comments?
> >>
> >>
> >> [previous explanation]
> >>
> >> It might be best to begin by setting out the array of information we may
> >> want to record with these tags. I've already listed three items:
> >>
> >> 	appName (human-usable application title)
> >>
> >> 	appURI (i.e. where you could go to get the application, or info about it)
> >>
> >> 	appVersion (conventional dot-separated Major, Minor, Release and Build
> >> integers)
> >>
> >> I think this may also be very useful:
> >>
> >> 	appId:
> >>
> >> This would be an identifier for the application which conforms to xml:id
> >> constraints. Such ids are used by application developers, for example to
> >> create a mutex when an application is running in Windows, so that an
> >> installer or uninstaller can check to see whether the application is
> >> already running before attempting to install it or uninstall it.
> >>
> >> We can imagine lots of others, relating to licensing (GPL, Moz 1.1,
> >> etc.), registered user, programmer or publisher, but these are less
> >> important and more difficult to constrain to a fixed format.
> >>
> >> I prefer "app" to "product" as a prefix; "product" has a rather nasty
> >> marketing-speak flavour about it to me, although that's a personal thing.
> >>
> >> There is an analogue for all this in the Windows file versioning
> >> information system (and presumably on other platforms too). Any Windows
> >> executable can contain a data structure which encodes a range of
> >> name-value pairs, many of which are formally documented and expected
> >> (major version, minor version, build, release, etc.) and some of which
> >> are conventional, but it also allows you to add your own name-value
> >> pairs and use standard API calls to retrieve them. If we're considering
> >> creating a new structure or set of tags, I think it would be a good idea
> >> to follow a similar model, with some items we'd expect the application
> >> to add to the file, but with the flexibility for other information to be
> >> encoded in a standard way. Something like this is what I imagine:
> >>
> >> <creatorApp>
> >>     <appIdent key="appId">ImageMarkupTool1</ident>
> >>     <appIdent key="appName">Image Markup Tool</ident>
> >>     <appIdent key="appVersion">1.0.3.5</appIdent>
> >>     <appIdent key="appURI">http://..../</appIdent>
> >>     <appIdent key="userDefined" userKey="licence">Mozilla Public Licence
> >> 1.1</appIdent>
> >>     <date value="2006-05-25T11:03:55">Last save: 2006-05-25 at
> >> 11:03:55</date>
> >> </creatorApp>
> >>
> >> With a system like this, getting all the available info about an
> >> application is simply a question of iterating through the appIdent tags.
> >> specific info can be retrieved using the key attribute (or whatever
> >> would be a better name for it). The key attribute could be constrained
> >> to an enumeration which also includes "userDefined", and that could be
> >> used in combination with an unconstrained userKey attribute to add any
> >> info the developer thinks is required.
> >>
> >> The date tag is useful in this scenario:
> >>
> >> We can envisage multiple applications working on a file in sequence, and
> >> it would be politic not to destroy the creatorApp information about
> >> previous applications. For instance, imagine that someone creates a
> >> really powerful and intuitive tool for building teiHeaders, and that's
> >> all it does. You might mark up an image using the Image Markup Tool
> >> (which lets you edit the teiHeader as text, but doesn't help you with
> >> it), and then use the teiHeader tool to add an elaborate header. You
> >> could then edit the file again in the Image Markup Tool (which wouldn't
> >> damage or change any elements of the teiHeader other than those which
> >> directly concern it). It would be important to know which of these
> >> applications was used to edit the file, and when. So each tool, assuming
> >> they're both using this proposed versioning system, would be able to
> >> identify its own creatorApp tag (using the appId) and modify that every
> >> time it edited the file, while leaving the other application's
> >> creatorApp tag alone.
> >>
> >> Does this make sense?
> >>
> >> I really don't want to customize my schemas to add support for this
> >> information; it really is useless if it can't be found in a predictable
> >> location in a reliable format, because the whole idea is that it be read
> >> and written automatically by authoring programs.
> >>
> >> [end of previous comments]
> >>
> >> Cheers,
> >> Martin
> >>
> >>
> 
-- 
Daniel Paul O'Donnell, PhD
Acting Chair and Associate Professor of English
Director, Digital Medievalist Project
<http://www.digitalmedievalist.org/>
University of Lethbridge
Lethbridge AB T1K 3M4
Canada

Vox: +1 (403) 329-2378/-2377
Fax: +1 (403) 382-7191