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

[Sebastian Rahtz]

> 
> We do, if we accept that the attributes have different meanings. Here's 
> the same example with some co-ords.
> 
> <surface ulx="0" uly="0" lrx="200" lry="270">
>>    <zone ulx="10" uly="10" lrx="100" lry="180">
>>       <line>Poem</line>
>>       <line>As in Visions of — at</line>
>>       <line>night —</line>
>>       <line>All sorts of fancies running through</line>
>>       <line>the head</line>
>>    </zone>
>>    <surface type="newsprint" binder="glue" flipping="false"
> 	ulx="50" uly="130" lrx="150" lry="220">
>   			
>              <zone ulx="50" uly="130" lrx="150" lry="220">
>                Spring has just set in here, and the weather.... a
>   			   steamer</zone>
>           </surface>
>     </surface>
> 
> This defines a coordinate space (0,0,200,270) on the outer surface, and 
> then a zone. and a nested surface containing a zone, all (ex hypothese) 
> within the same space. The positions and sizes *in that coordinate 
> system* for all of them are explicit.

So the coords on the inner <surface>, in this example, do a different
job from the coords on the outer surface - the inner one acts like
a <zone>, not a <surface>. This seems not good to me.

> 
> The problem which is worrying me, and possibly also Sebastian, is that I 
> have no way of distinguishing this case from the less likely but not 
> impossible case where the coordinates given for the inner nested surface 
> are actually defining a completely new coordinate system.
and if you _do_ that, then you don't know where the inner
surface is relative to the outer one.

>> This _could_ all work if we had _two_ sets of coordinates, one to
>> declare oneself relative to the outer<surface>, and one to
>> set a new new coordinate system relative to the outer one, but I really
>> cannot see how you can work with one set of coordinates.
> 
> A new coord system isn't *relative* to the outer one, methinks. It's 
> just new.
yes. but the coordinate world it defines _also_ needs to be defined
relative to the outer one.

> 
> Well, the recognition that we need both possible semantics is why I say 
> we need some way of indicating which applies in a given case. I can't 
> see that it would ever make sense to want both cases to apply for a 
> single instance!
yes, it does.

Your outer surface defines a grid of 0,0,1000,1000. the inner
one is at 10,100,500,500 within that 1000x1000. OK so far. It
now says that for <zones> within it, they will be described
according to a grid 0,0,4,4  So the inner zone at 1,1,2,2
can be placed on the _outermost_ surface by scaling it
up proportlonally from its place within 0,0,4,4 to its place within
out 10,100,500,500.

Honest injun.

> 1. Enforce somehow a rule which says that you can only have one coord 
> system in a given hierarchy of surfaces, and it is the one given by the 
> element at the root of that hierarchy (which will be either a surface or 
> a surfaceGrp or conceivably a sourceDoc). This involves no change to the 
> existing schema, but does require some careful rewriting and some 
> special case rules.
I agree, this is the easiest solution. But it does mean the nasty situation
where the meaning of coords on surface depends on context. Bearable.

> 
> 2. Introduce a new element <coords> which sits anywhere within the 
> hierarchy and defines the coordinate system for all of its children.
doesn't help, I claim. whatever you do, the inner object needs to
both declare a new coordinate system, _and_ relate itself to its parent

> 3. Introduce a new attribute @coords for <surface> or <surfaceGrp> which 
> defines the coordinate system for all of its children. Cannot co-exist 
> with either the ulx, urx etc. quartet, or the @points.
on the contrary, I say that it would _have_ to co-exist!

> I think all of these are less ugly than sin. Any preferences? Any 
> alternatives.

go back to <patch> and give it semantics of <zone>, and forget
about allowing for change of coordinate system.

I actually prefer 3), with my reversal of meaning

> 
> One other thought about all this -- might it be worth sounding out the 
> person responsible for much of our current thinking on this topic, i.e. 
> Conal, as to how he rates our development of it ?


can certainly do no harm.
--
Stormageddon Rahtz      
Head of Information and Support Group, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente