Very fast-and-lousy reply; apologies.
> ... suffers from the problem that the two classes must be
> disjoint if we are to avoid "non-deterministic content model"
> errors in DTD land.
I don't think DTD restrictions should be governing us, here. Yes, we
may have to do some work to get around the fact that trang is not
going to automatically generate a DTD from the RelaxNG equivalent of
a non-deterministic content model, but it seems likely to be worth
> We've experimented with trying to define more rigorous content
> models, which aimed to simply duplicate the existing janus tags
> model, and found that they rapidly get rather complex.
While I accept that we've looked at this route and discarded it, I
think this reason is simply false -- the content models were not
> Moreover, it seems to me that in defining <choice> more generally
> as a mechanism for indicating places where a "choice" of
> encodings is feasible we are adding a useful new facility that
> could do more than the old janus tags provide.
Which leads us back to the (unanswered) ambiguity and levels
problems. See "Handle Ambiguity, Too" and "At What Level?" in my post
"where we are, where we can go, what we can do [take 2]" of
> The principle is the simple one of observing that the distinction
> between "source" things and "derived" things is hard to sustain
> in actual practice.
This does not make a lot of sense to me. While I'm sure any of us
can come up with real encoding problems where differentiating between
source and derived is problematic, we can equally easily come up with
cases where it isn't. My suspicion is that for the vast majority of
cases where one of the P4 Janus elements is applicable it is not at
all difficult to discern "source" from "derived".
> ... so you might want a choice of two <sic>s.
Why wouldn't you use (what I think of as) the correct encoding, a
<choice> of two <unclear>s?
> The application might, as Syd suggests, make that decision on the
> basis of the order in which alternates are presented, ...
I can't take credit for that idea ... I think it goes to Sebastian or
> One last point: there are several elements which carry a REG
> attribute, mostly names of persons or places. Should <name>
> (etc.) therefore also be a choosable element? I am not sure. It
> seems to me that e.g. <name reg="Edinburgh">Auld Reekie</name> is
> not really asserting that "<reg>Edinburgh</reg>" is an
> alternative way of encoding "<name>Auld Reekie</name>". Rather it
> is annotating the latter with some extra information,
To play devil's advocate: Indeed <name reg="Edinburgh">Auld
Reekie</name> is not really asserting that "<reg>Edinburgh</reg>" is
an alternative way of encoding "<name>Auld Reekie</name>". But it is
asserting that, for some (ostensibly large) class of applications,
only one or the other should be used.
> So I am now inclining to the view that those REG attributes
> should either be removed entirely,
Bad idea, methinks.
> ... or replaced by child <reg> elements for <name> etc.
See http://www.tei-c.org/Drafts/edw79.html#back.1_div.1 for a (quite
old) discussion of this issue.