#369 *Spec elements could have <keywords> or use @ana

RED
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

Discussion

  • Sebastian Rahtz

    Sebastian Rahtz - 2012-07-23

    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.

     
  • James Cummings

    James Cummings - 2012-08-09
    • assigned_to: nobody --> rahtz
     
  • James Cummings

    James Cummings - 2012-08-09

    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.

     
  • Lou Burnard

    Lou Burnard - 2012-09-16

    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?

     
  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: --> RED
     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-09-16

    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".

     
  • Martin Holmes

    Martin Holmes - 2012-09-21

    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.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-05

    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 :-}

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-01-05
    • assigned_to: rahtz --> nobody
     
  • James Cummings

    James Cummings - 2013-01-08

    Assigning to jcummings to remind me to come up with a more detailed proposal; leaving as RED for now.

     
  • James Cummings

    James Cummings - 2013-01-08
    • assigned_to: nobody --> jcummings
     
  • James Cummings

    James Cummings - 2013-11-13
    • status: open --> closed-out-of-date
    • Priority: 5 --> 1(low)
     
  • James Cummings

    James Cummings - 2013-11-13

    closing at 2013-11 face-to-face