[tei-council] zones inside zones?

[James Cummings]

Would one of you relate this back to TEI-L for those who were 
following that discussion? The others in the discussion might 
appreciate it.

Best,
-James


On 30/04/12 18:13, Martin Holmes wrote:
> 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
>>>>
>>>
>>
>


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford