This is an extremely interesting, useful discussion about which I do
have a lot to say. But being pressed for time at the moment, I will
only briefly address two issues now. And I realize that, by now, both
Sebastian & Wendell have posted further comments that I have not read
yet ... hard to keep up with keen intellects like theirs!
SR> I think Syd and I disagree on this; but I think a document can be
SR> checked against validity of lots of different schemas. to be
SR> conformant, the document validates against "tei_all", regardless
SR> of what hacked schema the author may have used along the way
To say I disagree with this is a monumental understatement. I
disagree with it so strongly, Sebastian, that I hope you don't
really mean this, and that it is really the case that
a) we are talking at cross-purposes, and
b) you simply haven't thought through the consequences.
I think we are, at least to some extent, talking at cross-purposes. I
think you are still proposing that conformance should mean something
with respect to effortless interchangeability. I do not think
conformance has much, if anything, to do with the actual ease of
interchangeability as I think you use the term. The two are
orthogonal issues. Conformance should not mean that I can send you my
documents and you can pop them into your system and "presto", it will
work. Conformance means that when I send you my documents you know
where to look to find out whether or not my documents will work in
your system, and if not, why not -- what needs to be changed in
either my documents or your system to get things to work.
If the TEI-C were to define conformance to mean validation against
'tei_all' it would be not just like shooting ourselves in the foot,
but like shooting ourselves in the foot with a large caliber weapon,
lacerating the dorsalis pedis artery -- we'd be hemorrhaging
scholarly users. Why? Because scholarly projects would not be able to
make all sorts of customizations which they would require. Some
- adding a 'subSubType' attribute to some element
- adding a new element for any reason
- permitting values other than what TEI currently permits, e.g.
permitting the value "0" for either the withId= attribute of
<tagUsage> or the writtenLines= attribute of <layout> (some might
argue that these would be bug fixes, BTW)
- renaming <l> to <metricalLine> just because you sometimes confuse
it with <lb>
It's that last one that really makes me think you haven't thought
this through, as I am pretty sure you are in favor of saying that
renaming elements does not violate conformance.
The second issue to discuss is the original question -- I'm worried
that Sebastian and Wendell have forgotten that Ron Van den Branden
*can* in fact remove numbered <div>s from his schema using ODD. It's
just that he can't do so *easily*. He needs to dive into the RelaxNG
code, just as he would have had to dive into the DTD code in P4. That
is, if he insists on using DTDs, ODD has not gained him anything with
respect to ease of modification in this case. But it hasn't lost him
For those interested, an example of doing this is available at
http://www.tei-c.org/wiki/index.php/FAND2_replace. It is a lot of
work, and appropriately intimidating -- one needs to know a lot about
Relax NG syntax and deterministic content to remove numbered <div>s
this way, but it works.
Note, however (as I think Sebastian has already mentioned), smarter
ODD to DTD software could, in theory, rewrite content models from
which all members of a class have been removed such that the result
is deterministic but validates exactly the same set of documents as
the non-deterministic simple version. I don't think this is easy, but
I do think it is possible.
Certainly it is easy to see what to do in Lou's example case:
(model.foo*, model.bar+, model.foo*)
( model.foo* )
iff model.bar is empty.