On Fri, 12 Jul 2002, Ingo Mittendorf wrote:
> I have been advised to specify which elements I was intending to move into a
> different class, because doing so might have some terrible effects.
> I was mostly thinking of moving FW to Incl. (A habitat of empty elements, I
> This has been suggested a couple of times on this list already. I scanned
> the Archives whether this was considered to be a problem, and I couldn't
> find anybody shouting a loud 'NO'. But then, all the discussions seem to
> have petered out before some final judgement was passed on the idea.
I think we decided to move fw to the refsys class, and remove it from
m.phrase. Its presence in m.phrase is what causes the problem. Your (and
others') observation that it should be possible to put it wherever a <pb>
goes is pretty hard to argue against -- and its presence in m.phrase is
thus plausibly a corrigible error.
> Since FW can only contain phrase level elements (and its text content will
> hardly ever be more than a couple of words), I couldn't see a problem with
> wild Div's or so sneaking in through the backdoor into places where they're
> elementa non grata
> [As I'm at it, I'd like to point out that, although FW may be contained in a
> wide range of elements (now in P4?), LG and SP are (still) not among them.
<lg> and <sp> have rather specific content models because they are really
"grouping" elements, used to wrap up a collection of lines in the first
case, and a speech and its speaker in the other. I don't see any great
conceptual difficulty in locating the <fw> (or whatever) within the
nearest child-of-lg or child-of-sp, rather than directly within the lg or
> That's mostly where I need them, and I could simply add them to the content
> models, but who knows where else I may suddenly need them where they're not
> permitted? Basically they should appear anywhere where PB occurs, and Syd
> Bauman mentioned he made such a modification for their project, which I kind
> of take as Approval.
> I'm no expert on content models, but could it be that their rather peculiar
> content models (idiosyncratic elements plus nothing but Incl) makes them
> drop out so often in terms of elements that one would kind of expect to be
> valid inside them, somehow, somewhere?]
> Two other elements I had thought to add to Incl: DEL and ADD. As other
> people who've posted to this list, I'm unhappy with addSpan and delSpan and
> all that business with anchors and XSL processibility.
What's your big problem with the pointer solution? There really
isn't any other, I'm afraid!
> -- This is in double brackets because it has NOTHING to do with TEI
> directly whatsoever. Anybody taking offence at this being in this posting to
> the TEI-L, please skip the following paragraph! --
> If anyone could tell me how to EFFICIENTLY process delSpan together with DEL
> XSLT-wise, could you please contact me personally?
Questions on how to process TEI elements using XSLT (or anything else)
are very much in scope for this discussion list, so I hope you'll post a
summary of whatever responses this question gets!
> My headaches about DEL and ADD in Incl are far greater than those about FW
> being in this class.
> I thought about including them in a hierarchically slightly lower class, but
> which should that be if I want to mark whole paragraphs or stanzas (LG's) as
Precisely. You can't have an element which spans hierarchic boundaries in
XML. Hence the need to use the pointer solution. See the chapter of the
Guidelines on non-hierarchic structures.
> Since I abhor delSpan and addSpan, I've worked around these by using DEL and
> ADD on single lines, ie:
> Not ideal, I'm not happy, but better than delSpan in any case.
What's wrong with delSpan?
> I've only got two instances where some such markup is required. They are in
> my 'unsolved problems box', and I am still thinking about a better solution,
> possible <lg rend="deleted">. Would do in that case, but I'd have to pray
> that I never come across a stanza that is deleted and in italics. (We don't
> use multiplex rendition values - "italics-deleted" -, I don't think we will
> ever need them elsewhere, not for our purposes.)
> At least "<element rend="deleted">" could easily be processed together with
> I know that at least one project moved DEL and ADD (and others) into Incl.
> So, is this defensible?
Not in my book! They must have made an awful lot of other changes to get
that to work -- ambiguous content models would pop up all over the place.