[tei-council] Monday ticket agenda

[Martin Holmes]

Sebastian Rahtz wrote:
> On 7 Feb 2010, at 16:44, Lou Burnard wrote:
> 
>>     * 2714682: permit <biblScope> as child or as sibling of <imprint>
>>        -- at present we allow either. This is confusing. Is it right?
> 
> at first sight, seems like a mistake being a child of imprint. can someone
> see an example where its wrong to have biblScope as sibling?

I favour having it in both places -- If it's no longer allowed as a 
child of <imprint>, I'll have hundreds of documents and a huge amount of 
XSLT to fix. :-)

On the larger issue, though, I don't really know what <imprint> is 
doing, exactly. One reason I'm beginning to move away from <biblStruct> 
in favour of <bibl> is that the structness of it doesn't make much sense 
to me, and makes processing quite hard. I'm never sure why some elements 
are direct children of <biblStruct> and some show up in <imprint>.

>>     * 2812634: @docStatus on <edition>
>>     * 2909766: made del and add dateable
>>       -- these both relate to use of TEI for born digital docs.
>>       not unreasonable stretches
> 
> yes please, its time to get off the fence!

Seconded.

>>     * 2925031: @ident datatype on <valItem>
>>       -- what is the diff between data.code and data.enumerated
>>
> I've got a lot of sympathy with this request, it bites me all the time.
> but the proposed solution using <val> breaks backward
> compatibility more than somewhat, surely? allowing
> either @ident or <val> seems messy. I'm more inclined
> to give <valItem> its local defintion of @ident

As a newbie, I realize I don't know whether, or under what conditions, 
changes to P5 that break backward compatibility would be allowed. Is 
there a policy on this? I would tend to assume that any changes to P5 
should maintain backward compabitility with previous iterations of P5, 
while anything that would break compatibility should be moved forward 
into the plans for P6. Is that how it works?

Cheers,
Martin