Print

Print


Hi there,

Conal Tuohy wrote:
> Martin Holmes wrote:
> 
>> The pattern is that something is described in the header 
>> (maybe by means 
>> of a feature description, maybe using other tags such as 
>> creatorApp, but 
>> with a unique ID) and then elements elsewhere in the document are 
>> associated with it by means of an attribute pointing to the ID value. 
>> The pattern is useful for all sorts of different types of item, from 
>> linguistic feature structures to creatorApp. 
> 
> See the "declarable" and "declaring" classes:
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-att.declarable.html
> http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-att.declaring.html
> 
> "Associating Contextual Information with a Text"
> http://www.tei-c.org/release/doc/tei-p5-doc/html/CC.html#CCAS

This looks like it would be right, but I see a couple of objections. 
This in the description of declarable elements:

     * every declarable element must bear a unique identifier
(Good, that's what we want for creatorApp, but...)

     * for each different type of declarable element which occurs more 
than once within the same parent element, exactly one element must be 
specified as the default

This would suggest that if creatorApp is a declarable, and there are 
multiple creatorApp elements (which our discussion of tools would seem 
to suggest may well be normal), then one would have to declare itself a 
default. We could arbitrarily say that the last tool to work on the file 
might make itself the default, and "demote" any other tools described in 
other creatorApp tags, but I don't know whether this is appropriate 
really. If two tools are concerned with operating on completely 
different areas of the file, and are not interested in what the other 
does, other than being concerned to preserve its work undamaged, it 
would seem strange for one to have "default" status. But perhaps I'm 
over-thinking this. However, declarables include langusage, which looks 
to me like a very typical example of the intent of this class 
(everything in the file must be in one language or another, so it makes 
sense to have a default if you're specifying anything at all), and Lou 
has already pointed out that the creatorApp proposal is substantially 
different from langusage in many respects.

There is another issue, too, when we come to the decls attribute. This 
attribute is what we might use instead of the proposed new global 
attribute "tools"; it is intended to link any major structural element 
to something declared in the header (good), and it can link 
simultaneously to multiple declared things using a space-separated list 
of ids (also good). However:

     * Each element specified, explicitly or implicitly, by the list of 
identifiers must be of a different type.

I think there is a reasonably strong possibility that more than one 
editing tool may wish to "declare its interest" in a given element in 
the file, and if they are all defined in the header as creatorApp tags, 
then this would be impossible using the decl tag, because they would all 
be of the same type.

So it seems to me that while declarable and declaring classes are 
similar to the kind of thing we're proposing, they're sufficiently 
different to make an uncomfortable fit; shoehorning editing-tool 
information into the structures available through these classes would 
disallow some useful aspects of our proposal.

Cheers,
Martin






-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]