#268 add @facs to <pb/>

Tite (11)

In Tite, @facs is missing as an attribute on <pb/>. This is needed to indicate the correspondence between page images and encoded text. Some prose giving instructions on how to use this attribute should also be added.


  • Laurent Romary

    Laurent Romary - 2010-12-15

    It's obviously an essential thing to have for any project requiring a basic link between text and image. +1

  • Kevin Hawkins

    Kevin Hawkins - 2011-02-21

    Hearing no objections from Coucil, consider this adopted.

  • Lou Burnard

    Lou Burnard - 2011-02-22

    In canonical TEI, @facs is globally available, if you add it. That might (or might not) be desirable for Tite, methinks.

  • Laurent Romary

    Laurent Romary - 2011-02-23

    Lou. Need a clear statement. Are you suggesting to use @facs globally (as in mainstream P5) to implement this ticket. If yes, and with approval of Kevin, we can move ahead.

  • James Cummings

    James Cummings - 2011-02-23

    What about re-adding @facs *just* to pb. Although this means it is maintained outside the class system, it doesn't break conformance (as long as it is a clone of the @facs that tei:pb would get anyway in tei_all).

    I would be against adding @facs globally in Tite but in favour of adding it just to tei:pb. The point of Tite is to be a highly constrained version of TEI which mass-digitizers are able to target their processes towards. I think having it globally fights against that. We don't want Tite edging towards becoming Lite. With Tite I'd prefer to err on the side of excluding things frankly, rather than including them.

  • Kevin Hawkins

    Kevin Hawkins - 2011-02-23

    I think the real point of Tite is to provide a constrained version of TEI suitable for encoders, who want exactly one way to encode any textual feature they might encounter.

    From what I can tell, the vision here is to use pb@facs to point to a page image but graphic@url to point to an image of something smaller than a page. So we only need @facs on pb. In line with James's reasoning, we should only add where needed even if this would go against the class model in P5.

  • Lou Burnard

    Lou Burnard - 2011-02-24

    I've no problem with the idea of saying that only <pb> should get @facs in lite, but the point of my comment was that it is not obvious how to avoid other things getting it too. In general, I think "cloning" attributes is not good practice, so it would be a useful exercise to see whether it is now possible to make just one element in a schema inherit from a supposedly global class. That was after all one of the purposes of the changes made for release 1.9

    In response to Kevin's comment on the ticket: there is a big difference between pb@facs and graphic@url -- the latter means that there is an image here which forms *part of the text* -- the former means that there is an image of this part of the text here, but it is not a textual constituent.

    I'm also a bit surprised to learn that data capture agencies want to use this feature: are they going to be supplying page images too? If so, shouldn't we be going the whole hog and adding <facsimile> and <surface> (at least) as well?

  • Kevin Hawkins

    Kevin Hawkins - 2011-02-25

    Lou's explanation of the distinction between pb@facs and graphic@url is a more precise way of describing what I was trying to say. That is, pb@facs is to be used to point to a facsimile of the whole page (which is either provided to the vendor as the source of their work or is created by the vendor by scanning from the source document), whereas graphic@url is used to point to an figure that appears in the text.

  • Lou Burnard

    Lou Burnard - 2011-03-20
    • assigned_to: nobody --> kshawkin
  • Lou Burnard

    Lou Burnard - 2011-03-20
    • milestone: --> Tite
  • Sebastian Rahtz

    Sebastian Rahtz - 2011-09-18

    if you want @facs just on <pb> (sure, why not, if the users need this), then

    a) remove membership of att.global in class att.global.facs
    b) make pb an explicit member of att.global.facs

    and you should be done.

  • Kevin Hawkins

    Kevin Hawkins - 2011-11-02

    Turns out this was already done at revision 8764, which, despite the confusing Subversion commit message, is when Lou implemented ticket 3136934.

  • Kevin Hawkins

    Kevin Hawkins - 2011-11-02
    • status: open --> open-fixed
  • Kevin Hawkins

    Kevin Hawkins - 2011-11-02
    • status: open-fixed --> closed-fixed