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

[Lou Burnard]

On 13/11/11 16:15, Sebastian Rahtz wrote:
> I think my problem is that I don't understand how you thought nested<surface>  was ever going
> to work. In the given example:
>
> <surface>
>     <zone>
>        <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">
> 			<zone>Spring has
>        just set in here, and the weather.... a
> 			   steamer</zone>
>
> there are no coordinates, but we can imagine that the outer surface might have had
> 0,0,100,100 and the<zone>  with the<line>s might have 10,10,23,42. But
> how were we ever going to know where the inner surface _is_? it is all very
> well to say you want that<surface>  to have a grid of 0,0,10,10, and then talk
> about the Spring<zone>  within it, but we have no means of anchoring this
> surface relative to the outer one.

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.

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.



>
> 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.

Lou's
> notion that you have a switch which flips between the two uses of coordinates
> cannot fly, because you need both.

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!

If you don't like the idea of an attribute (I don't much) I have three 
other suggestions:

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.

2. Introduce a new element <coords> which sits anywhere within the 
hierarchy and defines the coordinate system for all of its children.

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.

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

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 ?


>
> The example above is just fine to describe the structural relationship
> between what we see on the MS, but not the layout. IMHO.
>
> Simplest suggest is to abandon the idea that we'll ever be able to say _where_
> the patch is, and just accept that each new<surface>  is in its own
> little world, with its own coordinate space.
>
> My next suggestion is that we say that inner<surface>  cannot have
> coords, and that its simply a way of grouping<zone>s. In which case
> perhaps you'd rather call it a<zomeGrp>? in that case, I'd
> vote for going back to<patch>...
>
> My last suggestion is that we add a new set of x1,y1,x2,y2 attributes
> called rel_llx, rel_lly, rel_ury,rel_urx to<surface>, which allow it
> to say where it is relative to its parent<surface>. Ugly as sin, but
> it would work.
>
>
> --
> 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
>