LB> I think we decided to move <fw> to the 'refsys' class, and remove
LB> it from %m.phrase;. Its presence in [the phrase model class] is
LB> what causes the problem. Your (and others') observation that it
LB> should be possible to put it wherever a <pb> goes is pretty hard
LB> to argue against -- and its presence in %m.phrase; is thus
LB> plausibly a corrigible error.
I certainly have recollections of discussing this, but I don't
remember whether or not we ever committed to doing it. Maybe. But
rather than spend time searching the archives of TEI-L and through my
e-mail notebooks for what we may have decided in the past, I propose
we just move forward. I'm going to go out on a limb and claim this is
a corrigible error:
* The DTD is obviously wrong as published, and no reasonable case can
be made for <fw> to be a member of 'm.phrase'.
* There is an obvious fix: move <fw> to 'm.Incl' or 'm.refsys' (Lou
prefers 'm.refsys'; I could probably be talked into either).
* This fix is backward compatible: there are no documents that are
valid against a current P4 DTD that would be invalid against the
same view of the fixed P4 DTD (i.e. with <fw> in 'm.refsys' instead
I invite any and all to provide arguments or evidence to the
contrary. If there is a concensus (loosely defined as no objection
within the next week that isn't convincingly countered), we'll make
the change (i.e., move <fw> from 'm.phrase' to 'm.refsys') shortly
LB> <lg> and <sp> have rather specific content models because they
LB> are really "grouping" elements, used to wrap up a collection of
LB> lines in the first case, and a speech and its speaker in the
LB> other. I don't see any great conceptual difficulty in locating
LB> the <fw> (or whatever) within the nearest child-of-lg or
LB> child-of-sp, rather than directly within the lg or sp itself.
Sort of a moot point given the above, but I think I'd take issue with
it anyway. If the introductory prose ends on page 16 and the first
poem starts on page 17, you're suggesting that the <fw> needs to go
inside either <front><div><p> or <body><lg><head> (depending, I
suppose, on wether it's an <fw> marking something that occured
towards the bottom of p. 16 or towards the top of p. 17)?
end of long, boring, introduction.<?fw?></p>
<head><?fw?>On New Guidelines</head>
<l>Encoders would snore,</l>
<l>But now they dance,</l>
<l>Right out the door.</l>
<!-- more bad poems here -->
While I concede that it may not be very important to most users, it
does seem a bit nightmareish to describe where on the page the <fw>
was. Probably wasn't centered with that heading; and, of course, your
table-of-contents generating software now needs to know to extract
<fw> from the contents of <head> before putting it in the TOC.
LB> What's your big problem with the pointer solution? There really
LB> isn't any other, I'm afraid!
I'm with Lou on this. At least in the case of deletions, you can come
up with any content model of <del> and put it in any class you want,
and I can create a document with a deletion that you cannot encode
with <del>, but you could with <delSpan>.
I can well see a project deciding, for the sake of consistency, to
always use <addSpan> and <delSpan> and never to use <add> or <del>
(which are, in some sense, just a convenience for use when the
addition or deletion happens to map neatly into the logical hierarchy
of the document; which arguably is the majority of cases, but
certainly not all), but I cannot see the reverse as being possible in
anything but specific limited circumstances.
IM> I know that at least one project moved <del> and <add> (and
IM> others) into 'm.Incl'. So, is this defensible?
LB> Not in my book! They must have made an awful lot of other changes
LB> to get that to work -- ambiguous content models would pop up all
LB> over the place.
While I won't go nearly as far as Lou in saying this is indefensible
(at least not yet; someone may convince me otherwise) -- heck, we did
it with <add> at the WWP -- I think the important thing to realize is
that doing so doesn't relieve you of the need for <addSpan> and
 This isn't entirely true. If you're willing to use the additional
tagset for linking, segmentation, and alignment and specify id=,
prev=, and next= on your <del>s, then you could come up with an
element declaration (contentspec 'ANY') and class ('m.Incl') for
<del> that would allow encoding of almost any deletion (although
a few might still escape, one could argue that those represent
errors in the DTD). If, as you read this idea, you're thinking
"that's nuts", I think you're on the right track.