[tei-council] how about this one?

[Lou's Laptop]

I think I agree with Conal here. A zone defines some area within the 
co-ordinate system defined by its parent surface. Nesting has no other 
significance. If you allowed one zone to nest within another, the inner 
zone would still have to define its area in terms of the co-ordinate 
system defined by its grandparent surface. Therefore there is nothing to 
be gained by nesting zones within each other. I considered other 
possibilities for approx one nano second, before deciding that the 
possible loss in prolixity was not worth the definite increase in 
complexity.



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
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>