[tei-council] how about this one?

[Arianna Ciula]

I am convinced and thanks-you for the explanation. Does this also mean 
that is better to have the @box attribute for <surface>?

According to the example of images you had originally marked at 
http://tei.oucs.ox.ac.uk/trac/TEIP5/attachment/ticket/291/fax-example.jpg, 
assuming we are now adopting the new draft I would think that:

- what is marked there as surface is still surface, correct?
- what is marked there as graphic remains a <graphic> but within a 
<zone> (the outer zone)
- the zone elements remains such but will contain <graphic>s

If the @box attributes alone can allow us to determine which zone is 
inner and which is outer without the need to complicate things with 
nesting, do we still need @box for <surface>?
Sometimes the actual page of a codex doesn't correspond at all with the 
what was original size of the page because of cropping, damage, invasive 
restoration etc. and can be often reconstructed using old rules of 
proportion between the extant textual mirror and the original width of 
the margins. I can see a possible confusion here. Would my @box for 
<surface> encode the coordinates of the current page based on the images 
I have or the supposed size?

I am not trying to be pedantic here, but just to understand the rational 
behind the proposed markup.

Arianna

Conal Tuohy wrote:
> Hi Arianna
> 
> Just one point I wanted to pick up on from your email:
> 
> On Wed, 2007-08-15 at 17:32 +0100, Arianna Ciula wrote:
>> Things get 
>> complex though, because I think <zone> would have to allow nesting.
> 
> I don't think this is true ... see below
> 
>> To give a concrete example, since I would argue that, depending on the 
>> interests of the encoder, the opening of a book could be considered a 
>> <surface> where the wrapper <zone> could contain the <graphic> for the 
>> opening and two further <zone>s children (the two pages contained in 
>> it), we could have:
> 
> So this is a "double-page spread", right?
> 
> I agree that it should be possible to treat this as either 2 surfaces,
> or as a single surface (with a crease down the middle ;-)
> 
> In your example, you've used nested zones, like so:
> 
> <facsimile>
> <surface xml:id="opening157-158">
>    <zone xml:id="op157-158" box="...">
>      <graphic url="op157-158.png"/>
>      <zone xml:id="157v" box="...">
>       <graphic url="157v.png"/>
>      </zone>
>      <zone xml:id="158r" box="...">
>        <graphic url="158r.png"/>
>      </zone>
>    </zone>
> </surface>
> </facsimile>
> 
> However, I don't think it's necessary to use nested zones to do this,
> since presumably the areas defined by the @box attributes of the nested
> zones "157v" and "158r" will fall within the area defined by the @box
> attribute of the outer zone "op157-158". So the fact that the inner
> zones are graphically part of the outer zone is already expressed using
> the @box attributes and doesn't need to be redundantly expressed in the
> nesting of XML elements. 
> 
> I can see that nesting makes things more complicated for encoders, and
> even introduces the possibility of a difference between the inter-zone
> relationships expressed by the nesting, and those expressed by the @box
> attributes. For instance: it may be that the outer zone (containing a
> "double-page" graphic) has been cropped tightly to show only the 2
> pages, whereas the 2 inner zones (containing graphics of each page
> individually) might have substantial margins in which you can see a
> strip of the bed of a book-scanner. In such a case, these zone/zone/@box
> attributes might not fall entirely within the @box of their parent zone.
> In such a case, would you encode the single-page zones inside the
> double-page zone, or not? I don't think it's even helpful to pose this
> conundrum, so I'd recommend a single, flat, list of zones, without
> nesting.
> 
> Cheers
> 
> Con
> 

-- 
Dr Arianna Ciula
Research Associate
Centre for Computing in the Humanities
King's College London
Strand
London WC2R 2LS (UK)
Tel: +44 (0)20 78481945
http://www.kcl.ac.uk/cch