[tei-council] minutes/release deadline

[Martin Holmes]

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