[tei-council] zones inside zones?

[Lou Burnard]

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
>>
>