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

[Lou Burnard]

I am happy with the revised version below for inclusion in the minutes, 
and it doesn't contradict my revised version of the chapter (yet!).

However, on second (or third) thoughts, I still don't think it's 
actually entirely right.

Bear with me as I try to re-express what I think to be the case. (If 
you've had enough on the subject of <surface>s, stop reading now because 
this is going to be Long, and may make your head hurt)

In the simplest case, you have one <surface> and it defines a 
co-ordinate system -- four numbers -- which can be used to define the 
positions and size of other things relative to that surface, e.g. nested 
zones, or nested surfaces. The coordinates may or may not correspond to 
the dimensions of  the real world object whose surface is being encoded. 
The other things may or may not be contained within the rectangle which 
the coordinate system also expresses.

Now suppose you have two surfaces, which represent the recto and verso 
of a leaf. Clearly these are the same size, but it doesn't necessarily 
follow that the coordinate system you use has to be the same for both of 
them. You might use a fine grid (i.e. one allowing more values between 
its two co-ordinate pairs)  for a surface with many zones on it. You 
might use a very simple grid indeed for a blank surface. So we want the 
ability to specify the co-ordinate system independently for sibling 
surfaces.

When I process the @ulx, @uly etc. values for a <zone> I know that they 
are defined relative to their parent zone, so I know how to map them. 
Things get complicated when  -- following our decision to use <surface> 
*also* for patches -- I find @ulx @uly etc values on a *nested* surface. 
Are these values also to be interpreted with reference to their parent 
<surface>? I think, probably, yes, most of the time. But I bet someone 
will say "no, they define a NEW coordinate system", and the confusion is 
not helped by the fact that we have the same set of attributes meaning 
something quite different.

If you agree with me, however, let's now try to see how <surfaceGrp> 
helps, or doesn't. As currently defined, this new element allows me to 
say anything I like about groups of surface. In the Paris meeting, I 
suggested it would be most useful for expressing that two <surface>s are 
encoding the recto and verso of the same leaf. You could also use it to 
express that your two surfaces encode the left and right side of a 
opening, if you think openings are more interesting than leaves. And you 
could use it to encode a gathering of leaves because it can self nest.

<surfaceGrp type="gathering">
<surfaceGrp type="leaf">
<surface type="recto" ulx="0" uly="0" urx="100" ury="100"/>
<surface type="verso" ulx="0" uly="0" urx="100" ury="100"/>
</surfaceGrp>
<!-- and so on for the rest of the gathering -->
</surfaceGrp>

<!-- next gathering here... -->

This is starting to look rather useful... but why oh why oh why can't I 
set a default value for those @ulx etc. coordinates rather than have to 
repeat them over and over again for every surface?

I know that this system is generic, and is designed to cope with 
non-codex like objects, or codex-like objects in which surfaces are very 
heterogenous. But it will also be used for Plain Old Ordinary codexes 
won't it? In which case it would be nice to say -- every surface in this 
thing uses the same coordinate space, and here it is, on the outermost 
<surfaceGrp>. Or to have some way of saying "this surface is a rogue one 
that defines its own coordinate system".

In any case,  we need to find a water tight way of knowing whether a set 
of coordinates is to be understood as  "relative" or as defining a new 
coordinate system. Maybe another attribute ("base"?) is needed?

Lou



On 11/11/11 21:43, Martin Holmes wrote:
> On 11-11-11 12:42 PM, Lou Burnard wrote:
>> I think this part of the minutes, while it may represent what we said,
>> is not what we meant.
>>
>> "LB: Take the single canonical example of a leaf: the size of a leaf on
>> one side is the same as its side on the other. Therefore we should allow
>> a default coordinate system on<surfaceGrp>. The group consensus now is
>> that<surfaceGrp>   should replace<patch>; it covers both the use case of
>> <patch>   and other cases such as four-sided monuments or leaves;
>> <surfaceGrp>   is a child of<surface>, and<surface>   is its child;
>> <surfaceGrp>   needs to be able to express its location and size within
>> the coordinate space of its parent<surface>, assuming it has a parent
>> <surface>."
>>
>> Firstly, we definitely agreed that a<surfaceGrp>   should NOT have the
>> ability to define a coordinate space, because if the surfaceGrp is
>> flippable (like a leaf) then ipso facto, the coordinates on the recto
>> cannot be the same as those on the verso.
>
> You're absolutely right. What I recorded there is what we originally
> said; it was only later than you and I, in the process of arguing about
> something slightly different, came to the realization that the
> coordinate space on a verso is flipped, and so we can't have a single
> coordinate space for a<surfaceGrp>.
>>
>> Secondly, I think we mostly talked about<surface>   (rather than
>> <surfaceGrp>) as replacing<patch>. Since a bunch of surfaces can also
>> be linked together physically (as in a leaf, or a bunch of postits) then
>> a patch might also be represented by a<surfaceGrp>   but not necessarily
>> -- e.g. in the case we currently discuss ( bits of newspaper pasted down
>> on the page), they have only one surface.
>
> I think we talked about both, and my memory is that we actually talked
> more about<surfaceGrp>, because we were focused on the flippable
> two-surface patch and the multi-surface booklet examples, which are
> admittedly edge-cases. We talked a lot about he most unlikely scenarios,
> because they're the boundary cases which the markup must be powerful
> enough to accommodate, but in the context of the Guidelines and examples
> we certainly need to focus more on the commoner cases.
>
> How about this for a re-draft:
>
> The group consensus now is that what we were thinking of as a patch
> could be represented either as a nested<surface>  (in the case of a
> single pasted object with only one significant face) or a<surfaceGrp>
> (in the case of a flippable two-sided object, or a multi-page booklet
> pasted onto the parent surface). Both<surface>  and<surfaceGrp>
> therefore need to be able to express their dimensions within the
> coordinate space of their parent<surface>; in the case of a nested
> <surface>, it may also define its own coordinate space which act as the
> context for<zone>  elements defined within it.
>
> Cheers,
> Martin
>
>>
>> On 11/11/11 10:01, Laurent Romary wrote:
>>> On this issue, I will post the link to the TEI-L as soon as I have the feeling that everyone is happy with the minutes as they stand. May I set Monday (Nov. 14th) as a deadline for any comment (which you can edit by yourself, BTW)?
>>>
>>>
>>> Le 11 nov. 2011 à 10:41, Piotr Bański a écrit :
>>>
>>>> * is there a deadline for publishing the minutes to e.g. the tei-c site,
>>>> or will they remain at the wiki? Or is there a deadline for some
>>>> official announcement of their existence? (while I browsed them as
>>>> Martin produced them, I would also like to give them one more run)
>>>
>>> Laurent Romary
>>> INRIA&    HUB-IDSL
>>> laurent.romary at inria.fr
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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