[tei-council] solving the Birnbaum Biznai

[Syd Bauman]

There are some previous points in this discussion I may get to later,
but I think it is very important to correct right away what I
consider a grave error in Sebastian's presentation about this new
development.

There has an ongoing arch to this story line for some time now. Like
any good story, there is conflict. On one side, led by Sebastian, are
the forces trying to make P5 a more elegant, internally consistent,
easy to modify system. To this hard-working team the class system
represents a marvelous tool or solution, to be implemented even at
the cost of some of the constraints that could otherwise be
expressed. 

On the other side are the forces, who include both me and David
Birnbaum, I believe, who believe that the constraints the Guidelines
describe are paramount -- if they can be correctly described with an
elegant, internally consistent, easy to modify system, great. But if
not, they should be expressed as is with a less elegant system.

The following corrections are an attempt to make sure the voices of
those who consider the constraints the Guidelines express to be
paramount are heard (even if eventually overruled).


> So if we accept that msdesc is currently broke, we have a choice:

>  1) uses classes, and introduce very relaxed content models which permit
>     elements to repeat in unwanted ways

While this is the solution the corpus linguists just agreed to at our
Council meeting (i.e., our decision on <textDesc>), the manuscript
description folks are not so eager to throw away the structure they
are particularly interested in. Without the buy-in of the MS
description community (currently represented by David & Matthew),
this is not something we should pursue.


>  2) use classes, with the proposed new meaning of what a "class" is

With some caveats that Sebastian already knows of (if he understood
my possibly inchorent mail :-), I think this is a Good Thing to Do
even though it does not, on its own, handle <msIdentifier>.


>  3) introduce and implement module dependencies, and accept that it
>     will be harder to guarantee schemas which don't have dangling
>     links

I must admit I don't understand the "harder" part here, but I
personally think implementing module dependencies in the ODD system
is a good idea even if we (the TEI) choose not to use it. Any one of
the hundreds of other XML languages that will be expressing
themselves using our ODD system any day now may appreciate this
capability.  :-)


Sebastian has not mentioned another solution:

4) Not fix the "problem", but rather document it: say "yes, in order
   to use module A you also need to load module Y" and "yes, in order
   change the content of element E you do have to get your hands
   dirty with RelaxNG code".


> Each of these routes is possible. The simplest is 1), which
> requires no new work.

And may be acceptable to solve this particular problem, but in the
long term, I think it is an extremely bad idea to have a policy of
decreasing the utility of the Guidelines in order to solve these
problems.

While I am not super fond of (4), it is *much* more acceptable than
(1).


> no work has been done, but it is not that hard to make Roma follow
> "suggests" links and tick an extra box by default. 

Am I correct that what you intend here is that when a module M is
declared its <moduleSpec> would have a suggests= attribute which
lists 0 or more other modules. Roma would then tick off the check
boxes for the other modules whenever M was selected? This is halfway
between (3) true syntactic dependency (you get an error if you select
M without one of its dependencies) and (4) just document it, and I
think may be a very good way to go.


> However, it will require serious work to look at guarenteed removal
> of dangling links.

I'm not sure I understand this.


> *Secondly*, if we do take route 2), it has serious implications for
> the non-ODD extension mechanism, ie using schema/dtd module
> fragments and combining them in a DTD subset or hand-written
> RelaxNG schema. 

I am personally 

* in favor of permitting non-ODD extensions in RelaxNG, although less
  strongly so than I was 1 year ago in Paris (where, IIRC, I was the
  only one in the room who thought such a mechanism was necessary;
  some people (CW?) even thought it was a bad idea)

* against bothering to support extensions in other (non-ODD,
  non-RelaxNG) languages, particularly DTD. (Yes, in 2002 or
  thereabouts we decided, with Syd leading the charge, that
  supporting DTD extensions was important. I have since reconsidered,
  and think it is a complete and utter waste of TEI time and effort
  to even think of it. I am also against bothering to support DTDs at
  all, but there I think there are reasonable arguments on both sides
  of the issue. But supporting DTD extesions seems all but silly.)