Another delayed message, confirming (I hope) that I am in broad
agreement with Dan's more recent message...
-------- Original Message --------
Subject: Re: [Tei-choice] terminology
Date: Sun, 04 Jul 2004 22:31:54 +0100
Daniel O'Donnell wrote:
> They say that hard cases make bad law. I do wonder, however, if given
> what I understand to be the fairly significant reorganisation of P5, we
> shouldn't consider rejigging all the janus pairs and assigning them
> individual content models based on their features. Hence I'd like to see
> an <abbr> janus tag that contained <short> and <long> tags (or
> equivalent), a <corr> janus that had <original> and <corrected> children
> (or equivalent), perhaps a sic janus that had the opposite pairing
> (though I suspect that would now be redundant), and of course, our app
> element which all reading has the correct children.
Yes, I think that's what should be done. But let's be clear on what we
mean by "janus" tags or we'll all go mad. I vote for restricting the
term to the existing two-facing tags like <sic> which have content that
means one thing, and an attribute that means the opposite. Let's not
start calling the replacement for this (the wrapper) a <janus> too!
We have to decide between the following strategies
1. for every existing janus tag <x> with attribute y, define a new
wrapper <xy> with content <x>, <y>
2. define a generic tag <z> with content such as ( (x?,y?) | (a?,b?) |
(c?,d?) )... to replace all existing janus tags x, a, c ...
3. define a very general tag <z> with no particular restriction on its
content, but a clear semantics that says "you can replace me by one and
only one of my children here"