So, to sum up this discussion: is it the general consensus on this list
that the Guidelines shouldn't be changed to allow <subst> within <line>?
Best regards,
--
Martin de la Iglesia
Goettingen State and University Library
Metadata and Data Conversion
Papendiek 14
37073 Göttingen
Germany
phone: +49 551 39 14070
room: 1.411
[log in to unmask]
http://www.sub.uni-goettingen.de/
Am 10.01.2012 15:46, schrieb Syd Bauman:
> I think Lou's on the right track, here. Clearly
> <choice>
> <unclear>zach</unclear>
> <unclear>zash</unclear>
> </choice>
> is important inside<line> (lest you be forcing people to go back to
> the old ways of encoding alternatives when inside<line>, which could
> mean using two different methods to encode the same phenomenon in the
> same project, which is undesirable; besides, the reasons we have
> <choice> is that nobody liked the old methods). However, there is an
> argument for keeping<sic>/<corr>, etc., out.
>
> Given that it is much easier for TEI-C to relax the content model
> later if there turns out to be widespread support for having some
> interpretive markup inside<line>, but much harder to tighten the
> content model up if the current philosophy is upheld, I'd be in favor
> of clamping down on the content of<choice> when inside<line> right
> away.
>
>> In and of itself surely<choice> is not interpretive? It just
>> records the fact that the encoder considers there's more than one
>> way to encode something. The issue ought to be rather what its
>> content model should be when it appears within<line>
>>
>> However, I would be the first to agree that the content models for
>> these new elements are not yet perfect. I hope that they will be
>> widely experimented with, and that we can reach a consensus rapidly
>> for the next release...
|