Thanks for all those replies.

If, as Lou Burnard, says, changing the class membership is such a problem (I
knew it was a problem,- except possibly for FW - but not perhaps quite how
big), I would advise that the Guidelines be very explicit on this and/or
discuss the problem in chapter 29 of the Guidelines in more detail. So far
they read:

"Class extension is always clean in that the set of documents matching the
DTD containing the extended class contains all of the documents matching the
original DTD. Class extension can imply either ***the addition of an
existing element to a pre-defined class***, or the addition of a new element
(as described in the next section) to one."
[Guidelines, 29.1.3., last paragraph]

That's basically a go-ahead.

> In my opinion, you should not change class membership of existing
> elements. Its class membership is a part of the definition of an element.
> If you want to change that, then you are defining a new element, which
> should (ipso facto) be given a different name.
[Lou Burnard]

Project that globally included ADD and DEL:
[4 Dec 2001]
I couldn't find any replies to this in which there was a protest. {Which
doesn't mean there weren't any. only that I didn't find them.}

FW to refsys, not Incl
I thought about this, too, but hesitated because FW is not part of any
reference system, properly speaking.
Is there any content model that lists refsys separately, (ie not implicitly
included in Incl)?

XSL related questions on this list.
I'm very grateful, and relieved, that both Lou Burnard and Syd Bauman
approved of addressing such issues on this list. I've been told off for
doing this before.
Clearly, I wouldn't wish to go into too much technical detail concerning XSL
transformations here, but then, XSL processibility always has a huge impact
on how I mark up our texts (given that TEI gives you so many choices), both
in terms of feasibility (probably more a question of my XSLT shortcomings)
and efficiency.

Other issues to be addressed separately.

Ingo Mittendorf