#522 Create att.global.styling for @rend, @rendition, and @style

GREEN
closed-fixed
5(default)
2014-12-05
2014-07-31
No

This arises out of a Council list discussion which followed an attempt to implement [feature-requests:#460] by overriding the att.global definition of @rend in the <elementSpec> for <list>. This caused problems with DTD generation, and a simpler approach was used, but Lou suggested in the discussion that these three attributes form a natural class.

I think there is a good case for this. Where one is used, the others are also likely to be used (especially with @rend and @rendition); and conversely, a simple born-digital document might not have any need for any of them. It also makes sense to document them together.

Related

Feature Requests: #460

Discussion

  • Sebastian Rahtz

    Sebastian Rahtz - 2014-09-23

    I might suggest that we take this to its logical conclusion and put everything from att.global into subclasses, so people can pick and choose from a list. However, if we're taking apart att.global, lets at the same time banish @n to the outer darkness, and revisit the idea of finding a way to limit the effect of @rend etc to the

     
  • Lou Burnard

    Lou Burnard - 2014-09-23

    It's not clear what "put everything from att,global into subclasses" means; which additional subclasses are you proposing? Are you also proposing to deprecate @n? And how exactly do you want to limit "the effect of @rend etc" ?
    I am not sure I agree that "where one is used, the others are also likely to be used" -- quite the reverse in fact; if you use @rendition you probably won't use @rend. But putting them into the same subclass still makes good sense.

     
  • Martin Holmes

    Martin Holmes - 2014-09-24

    @Sebastian: I don't see any other natural groupings in att.global that aren't already in subclasses, unless you think the @zxml: attributes form a natural group. I also don't see any reason to do any more than is suggested on the ticket; getting rid of @n will cause everyone to scream, including me -- I don't like @n, but there are lots of situations in which I can't find anything better. I think if you use @rendition you'll most probably use @style too, and vice versa, but perhaps not @rend. But if they're together, users of @rend may be encouraged to investigate the other options. As for limiting @rend to the text element, it sounds like a good idea, but what if my sourceDesc quotes something whose original typography is essential to understanding it? Or what if a particDesc contains a description of a person which quotes a picture of them in ascii art?

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2014-09-24

    "but what if my sourceDesc quotes something whose original typography is essential to understanding it?" are you serious? does this happen? I find it hard to accept that it is allowed by the TEI notional model.

    I'd put @n, @style, @rend and @rendition in a special class precisely in order to indicate that they are not acceptable if ancestor-or-self::teiHeader. they do differ from the xml:* ones in that those do apply to metadata. The subclasses all seem to me to be in the same state, ie only suitable inside <text>or <sourcedoc>

     
  • Martin Holmes

    Martin Holmes - 2014-09-24

    There would be much wailing and gnashing of teeth. But why is @n in this group for you? It has nothing to do with describing the appearance of an original text,

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2014-09-24

    eh? if @n is not about the numbering you see in the appearance of the original text, what on earth is it for? It's a (very) poor man's <label>, and should have been taken out and shot during the war on attributes.

    show me a real life <teiHeader> which uses any of @n, @style, @rend or @rendition in a defensible way, and I'll eat my hat^H^H^H^H^H^H^..... a hobnob.

     
  • Martin Holmes

    Martin Holmes - 2014-09-24

    @n: (number) gives a number (or other label) for an element, which is not necessarily unique within the document.

    Note

    The value of this attribute is always understood to be a single token, even if it contains space or other punctuation characters, and need not be composed of numbers only. It is typically used to specify the numbering of chapters, sections, list items, etc.; it may also be used in the specification of a standard reference system for the text.

    There's nothing in there that says it has to represent something that appears in the original text. If you use it for a standard referencing system, the implication presumably is that what goes in @n doesn't appear in the text. The note explains how it is "typically" used, but doesn't proscribe its use for anything else. I've used it for very short labels on <category> elements myself -- I have a long catDesc, a shorter gloss, and a very short @n that I can display in certain contexts where space is very tight. That might be attribute abuse from your point of view, but it's certainly not precluded by anything in the spec.

     
  • Lou Burnard

    Lou Burnard - 2014-09-25

    Certainly the prose and examples both warrant the use of @n to carry information transcribed from an original source e.g. the original numbering of a section etc. But it does not anywhere (so far as I recall) say that this is its only intended use. And there are certainly cases in the wild of people using it as a poor-man's xml:id or label, quite apart from Martin. So while I support the idea of defining att.styling, I don't think @n belongs in it. Note by the way that if you have an msDesc in your header and if that contains an msItem which includes quoted material, chances are you'll still need att.styling in the header.

     
  • Martin Holmes

    Martin Holmes - 2014-09-25

    So apart from Sebastian's radical desire to take this beyond what the ticket suggests, we seem to be in agreement that we should:

    • Create att.global.styling, containing @rend, @rendition and @style
    • Add that to att.global

    Anything else we need to do there? I can't think of any other implications for backwards-compatibility etc., except in cases where people have removed e.g. @rend from att.global; they'd now need to remove it from att.global.styling instead. Is that a major issue?

     
  • James Cummings

    James Cummings - 2014-11-17
    • assigned_to: Lou Burnard
    • Group: AMBER --> GREEN
     
  • James Cummings

    James Cummings - 2014-11-17

    Council Assigning to LB at F2F Raleigh 2014-11-17. Green.

     
  • Lou Burnard

    Lou Burnard - 2014-12-05

    Initial implementation shows that ODDs which attempt to delete the attributes now in att.global.rendition produce unexpected errors about duplicate declarations. Investigating.

     
  • Lou Burnard

    Lou Burnard - 2014-12-05

    This change has side effects so I have not yet checked it in: any ODD which tries to remove e.g. @rendition from att.global, rather than from (following this change) att.global.rendition, will get two declarations for @rendition. I suspect this may be a bug in ODD processing. In our test suite, the ODDs for testbare, testbasic, and testmeta3 are all affected.

    In the exemplars, tei_tite is also impacted, because it removes att.global from all its classes, and thus does not inherit the new att.global.rendition at all.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2014-12-05

    You could create a bug report on the Stylesheets if you can describe more precisely what is in error. Trying to delete an attribute (@rendition) from a class (att.global) in which it does not exist should simply have no effect. Not enough info to act at this point, sorry.

     
  • Lou Burnard

    Lou Burnard - 2014-12-05
    • status: open --> closed-fixed
     
  • Lou Burnard

    Lou Burnard - 2014-12-05

    Changes implemented and bug in oddtodtd all fixed in record time. Closing ticket, before anyone notices I have mistakenly named the new class att,global.rendition instead of att.global.styling as originally proposed.