[tei-council] surfaces, surfaceGrps, etc. [was : minutes/release deadline]

[Martin Holmes]

On 11-11-14 03:27 AM, Lou Burnard wrote:
> On 14/11/11 10:57, Sebastian Rahtz wrote:
>>
>> On 14 Nov 2011, at 05:09, Martin Holmes wrote:
>>
>>> <zone>   should be able to contain<surface>. You define a<zone>   to show
>>> the contextualized coordinates of the patch or whatever in the parent
>>> <surface>   coordinate space, then you put a<surface>   in it; the latter
>>> can then define its own coordinate space for<zone>s inside it.
>>>
>>> So the coordinates on<zone>s mean "my position and size in the parent
>>> space", and the coordinates on<surface>   mean "the coordinate space in
>>> which child<zone>s will be defined".
>>
>>
>> I like it, a lot. Simple and effective, no ambiguity, meets all the needs. Lets do it.
>> --
>
> This looks like a gordian-knot-breaker... many thanks Martin! I will go
> away and redraft accordingly.
>
> p.s. while we're at it, how about renaming ulx, uly etc as one attribute
> @coords for the "coord-space-definition" sense? a different name reduces
> confusion as well as the amount of typing. Or do we think this would be
> a birnbaum-breaker?

It's definitely birnbomb, and in my initial thought was that I'd have to 
go away and do a new release of the Image Markup Tool to handle this, 
but when I checked, I discovered that I'm not establishing a coordinate 
system on my <surface>s at all in the IMT output; I'm just assuming that 
the @width and @height attributes on the <graphic> child of <surface> 
constitute the coordinate space for the <zone>s. I hope that's still 
acceptable practice.

Nevertheless, I'd be nervous about breaking backward compatibility here.

Cheers,
Martin