[tei-council] zones inside zones?

[Martin Holmes]

Thanks Lou. Makes perfect sense. Sorry my memory is so faulty these days.

Cheers,
Martin

On 12-04-30 10:07 AM, Lou Burnard wrote:
> As one Martin Holmes noted on the Council list back on 10 Nov 2011,
> the co-ordinate space (defined by a<surface>) must be rectangular.
> Further, on 19 Nov 2011, one Sebastian Rahtz (remember him?) remarks
> categorically
>
> "it [the case where a<surface>  contains both coordinates and @point]
> is a plain ole error, I'd say"
>
> Holmes also says, on 20 Nov 2011m
>
> "I think we agreed that since<surface>  is always establishing a
> coordinate system, and a coordinate system must always be rectangular,
> we don't need @points on<surface>, only on<zone>.
> That gives us the rather odd possibility of a non-rectangular<zone>
> which contains a<surface>  that must have a rectangular coordinate
> system, though."
>
>
> THEREFORE since<surface>  inherits the coordination attributes from
> att.coordinated, @points should not be a member of att.coordinated.
> Faced with a choice of defining four attributes locally on several
> elements, or one attribute (@points) locally on<zone>, your humble
> editor obviously took the path of least effort.
>
>
>
> On 30/04/12 16:57, Martin Holmes wrote:
>> I'm bringing this discussion over to the Council list, because I'm a bit
>> puzzled about what we did with @points here:
>>
>> On 12-04-30 02:31 AM, James Cummings wrote:
>>> On 29/04/12 14:45, Conal Tuohy wrote:
>>>> It appears that the<zone>    element has expanded in scope since
>>>> the time we added it to TEI P5 1.0. At that time, if I remember
>>>> correctly, it could not nest, and in fact had a very limited
>>>> content model (just<gloss>,<desc>, etc.). At that time, the
>>>> Council's view was that allowing nesting of<zone>    elements would
>>>> add complexity without any additional functionality, and I
>>>> honestly don't know the rationale for the subsequent change.
>>>
>>> Digging around in the http://www.tei-c.org/Vault/P5/ confirms
>>> that the big change for<zone>    came in release 2.0.0 when we
>>> added the genetic editing abilities and<sourceDoc>.  It is at
>>> this point that it gets @points as a separate attribute
>>> (previously in att.coordinated), @rotate, and its element content
>>> model changes from:
>>> ( model.glossLike*, model.graphicLike* )
>>> to:
>>> (text | model.graphicLike | model.global | surface |
>>> model.linePart )*
>>
>> I don't remember deciding to remove @points from att.coordinated and
>> define it directly on<zone>. Looking at the SVN log, I didn't find any
>> mention of this, even though between 1.9.1 (May last year) and 2.0.0
>> (December) the change was clearly made. I found nothing on any of the
>> tickets that would prompt this change, nor did I see anything in Council
>> minutes that suggests we decided to do it.
>>
>> Looking closer, it appears the changes was made by Lou in rev 9790, for
>> which this was the message:
>>
>> "introduce model.linePart class; add line to it; move @coords out of
>> att.coordinated"
>>
>> However, there is no attribute @coords; a diff shows that it was
>> actually @points that was moved:
>>
>> svn diff -r 9789:9790 att.coordinated.xml
>> Index: att.coordinated.xml
>> ===================================================================
>> --- att.coordinated.xml	(revision 9789)
>> +++ att.coordinated.xml	(revision 9790)
>> @@ -83,15 +83,6 @@
>>             <rng:ref name="data.numeric"/>
>>           </datatype>
>>         </attDef>
>> -<attDef ident="points">
>> -<desc>identifies a non-rectangular area within the bounding box
>> -specified by the other attributes  by specifying
>> -a series of pairs of numbers, each of which gives the x,y coordinates
>> -of a point on a line defining the non-rectangular area.</desc>
>> -<datatype minOccurs="3" maxOccurs="unbounded">
>> -<rng:ref name="data.point"/>
>> -</datatype>
>> -</attDef>
>>
>> Lou, do you remember why you made this change? Doesn't @points belong in
>> att.coordinated? Or have I missed a discussion or a ticket somewhere?
>>
>> Cheers,
>> Martin
>>
>>> This is because in its new existence in<sourceDoc>    it is allowed
>>> to have transcribed (but un-interpreted) text in it. Nesting
>>> <zone>    elements inside<sourceDoc>    make more sense to me, but
>>> make much less sense inside<facsimile>.
>>>
>>> It might be a reasonable feature request to have a TEI schematron
>>> rule that reduced<zone>    as a descendent of<facsimile>    to not
>>> allow nesting, and only allow the equivalent of its original
>>> content model of (model.glossLike*, model.graphicLike*). That is,
>>> at least, how I'll use it in documents I encode.
>>>
>>> -James
>>>
>>
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)