Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
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.
It's obviously an essential thing to have for any project requiring a basic link between text and image. +1
Hearing no objections from Coucil, consider this adopted.
In canonical TEI, @facs is globally available, if you add it. That might (or might not) be desirable for Tite, methinks.
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.
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.
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.
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?
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.
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.
Turns out this was already done at revision 8764, which, despite the confusing Subversion commit message, is when Lou implemented ticket 3136934.