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:
> "Associating Contextual Information with a Text"
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.
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]