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

[Martin Holmes]

I said at the time, but I don't think anyone took me seriously:

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

Anything wrong with that?

Cheers,
Martin

On 11-11-13 09:35 PM, Lou Burnard wrote:
> 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
>>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived