[tei-council] http://purl.org/tei/fr/3519866 (@rend datatype)

Martin Holmes mholmes at uvic.ca
Thu Jul 5 12:58:26 EDT 2012


On 12-07-05 09:30 AM, Sebastian Rahtz wrote:
>
> On 5 Jul 2012, at 17:00, Lou Burnard wrote:
>
>>   Not to pre-empt further discussion, I observe that the
>> current datatype (1:n data.words) was a change deliberately (and quite
>> recently)
>
> well, it was there at the start of P5, so not _that_recent. I can spot
> the idea as far back as 2005.
>
>> It does not really permit arbitrary syntax (like rendition ladders or
>> local CSS), so that (legacy) constituency remains unsatisfied. At the
>> same time, it requires the user to tell fibs, so that progressive (if
>> anal) thinkers are also dissatisfied with it. As I said on the ticket,
>> the only sensible way to resolve this issue is to return to the status
>> quo ante bellum.
>
>
> which bellum? you want to go back to P4 and just allow anything?
>
> I'm coming round to the idea of a mandatory indicator in the header which says how
> @rend is to be interpreted (with a closed list of (eg) "token", "free" and "CSS"),
> since its unlikely we'll ever now close this awful Pandora's box.

I don't see why not. I think everyone (like me) currently abusing @rend 
by putting CSS in there can very easily switch to a new attribute 
(@style) instead. Anyone who refused to do so would remain guilty of 
attribute abuse, but without the excuse that they had no alternative 
(yes, I know there's always customization, but...). We could perhaps 
back up the move with a Schematron constraint that would complain at the 
appearance of semi-colons and colons in @rend, to encourage compliance, 
and we could even provide some degree of Schematron validation for CSS 
in @style.

Cheers,
Martin

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




More information about the tei-council mailing list