Menu
▾
▴
#369 *Spec elements could have <keywords> or use @ana
closed-out-of-date
1(low)
2013-11-13
2012-07-23
No
We should recommend a way to provide multiple arbitrary classifications to *Spec elements (e.g. elementSpec).
Two possibilities occur to me instantly:
A) Encourage use of @ana for this purpose pointing to a taxonomy
B) Introduce <keywords> as an allowed child of *Spec to allow terms within that to be used.
The use case is to classify elements according to any user-defined or other classification system to allow for more flexible use. e.g. the TEI-C XSLT has a function that hard codes guesses as to whether a particular element is used \'inline\' or not. but there could be a <term>inline</term> on all such elements so that this kind of magic was unnecessary. Similarly, ODD writers may wish to categorise elements for other purposes \"These are all the date-related elements from various modules\", or other more semantic or folksonomic groupings.
-James
with the proviso that no-one (I assume) yet points to an ODD from an instance;
so a processing XSLT will not have access to the information in the use case you note. also bearing in mind that tests about "am I inline" often involve a contextual test
but the general utility is good.
Any more comments on this?
I accept that in processing document instances this will be of limited use (unless the TEI adopts it throughout, I suppose).
Of the two I'm a bit happier with proposal B, by the way, since it seems easier to implement.
Sorery, but this seems too vague to be useful. @ana and <keywords> are both ways of classifying discursive artistic prose. *Spec elements are specifications. If you want to classify them you need to be more precise about the taxonomy concerned and what the classification actually does as part of the spec. I'd like to see some better use cases: to take the ones you have -- being used "inline" or not is a part of an element's model class surely. How does knowing that something is "date-related" help you do anything with it and what, indeed, does it mean?
It's true that the model class structure goes some way to help in the decision of whether this <thing> is really inline or not. Unfortunately so many elements are allowed in ambiguous contexts; <note>, for example, is allowed _everywhere.
I do think there is something needed, to avoid stylesheets like mine have a hard-wired is-inline() function with lists of elements, but it needs more experimentation. so I suggest, sadly, that we classify this proposal as "needs more work".
BB and MH discussing this at the ftf 2012-09 wondered why you couldn't just create classSpecs for this purpose, instead of using another mechanbism. The classSpec might have only this purpose. This would require the addition of an extra value for classSpec/@type, something like "adhoc", since such a class would be neither an attribute class nor a model class, but other than that, nothing disruptive would result, and a full description of what is meant by the categorization could be supplied in the classSpec. If at some point you wanted to do something with the class, you could make use of it in your schemaSpec, and change its @type from adhoc to something else.
I am removing myself from this, as there is no action at present. It needs a face to face debate,
and a decision between the many ways of implementing the functionality. As MH and BB note, the existing class mechanism would do the job just as well, though it does not solve the contextual problem.
ideas of a standardized TEI "processing model" are highly contentious :-}
Assigning to jcummings to remind me to come up with a more detailed proposal; leaving as RED for now.
closing at 2013-11 face-to-face