Print

Print


I guess my only question would be to double check the nesting. This
looks pretty flat: for example, i.e. there is no explicit relationship
between any of the elements describing aspects of the creator tool. Are
you assuming that if more than one tool is used each would have a
separate <creatorApp> element? Otherwise how would you know what
belonged to what.

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.

-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