[tei-council] surfaces, surfaceGrps, etc. [was : minutes/release deadline]
sebastian.rahtz at oucs.ox.ac.uk
Sun Nov 13 16:46:03 EST 2011
> 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>As in Visions of — at</line>
>> <line>night —</line>
>> <line>All sorts of fancies running through</line>
>> <line>the head</line>
>> <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
> 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
> 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
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.
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
More information about the tei-council