[tei-council] TEI next release
Syd_Bauman at Brown.edu
Sun Jun 18 11:40:26 EDT 2006
SB> As I've said before, I think it is much better to push out
SB> releases whenever P5 is in a reasonable and stable condition,
SB> rather than on some predetermined temporal schedule. This would
SB> result in much more frequent releases, giving us a much better
SB> image of "we mean business", and potentially giving us better
SB> feedback, etc.
SR> I do agree. But only if we work at a much faster schedule producing
SR> something where people will see a difference. As it is, the 6
SR> monthly release is the fallback to show the users _some_ signs of
Then I think actually we may disagree. I see no reason that a new
release should wait until there is sufficient difference that "people
will see" the difference. I think we should be pushing out a new
release pretty much every time we're pretty confident that
a) something non-trivial has changed (i.e. an explanation, the value
of an attribute, etc.), and
b) nothing is broken worse than the previous release
This might well entail 2 or 3 releases per month, or on occasion only
1 every few months. (And yes, we should feel embarrassed if nothing
non-trivial has changed in 6 months.)
As we've discussed before, my views
a) may be prejudiced by the fact that it's you who does the release
work, not me :-)
b) my belief that the work of creating a release is mostly
automatable, and should not take up much of your valuable time.
SR> OK, I can promise to do that before the release, ie not generate
SR> HTML with dangling links
Check, thanks. (I believe you've already done this.)
SB> IMHO one of the most important things to do ASAR is to fix the
SB> various problems with the roma-generated customized
SB> documentation. While this can be done independently of a release
SB> of P5, it is far more important, and should be done first.
SR> You'll have to remind me what these problems are.
Repeated from my mail to you of 2006-04-23T12:52-04, appended below.
Note that these are shortcomings of what's coming out from Roma the
web app. I can't tell what stylesheets it is using. When I use the
command-line roma.sh I get *serious* problems in the content models
whether I use
as the XSLDIR. (And yes, I have reissued `make dist`.) I get all
sorts of munge where content models should be. Here's what <date>'s
content model says:
| rng:text [ ]
| rng:ref [ name = "model.datePart" ]
| rng:ref [ name = "model.phrase" ]
| rng:ref [ name = "model.global" ]
This, in my mind, is pretty urgent, in that I'm teaching ODDs on Thu
22 Jun, and much prefer to use local command-line to quickly whip up
examples. (Yes, students use Rama-the-web-app.)
SR> Better, lets get them listed as bugs on Sourceforge, so that
SR> we have a record of what was reported and when it was fixed.
May be a bit, internet access spotty. (I can write mail locally and
post more easily than play with web forms.)
| You're kidding, right? Surely you realize that we need better than
| just proof-of-concept here at some point. Even if creation of these
| files were working as well as it was two months ago (and it isn't for
| me, it's pretty buggy now, but that may be something I've done
| locally), the output needs to be made more usable. To me this is a
| pretty high priority item, as there is a panel session at DH 2006 in
| early July during which several projects will be showing off their
| ODD files, and, most likely, the resulting customized reference
| documentation. TEI will look a lot more user-friendly and P5 will
| look a lot more usable if the reference documentation is very nice.
| Some thoughts, not intended to be exhaustive, in rough order of
| * HTML needs to be generic, placed under CSS control (e.g., instead
| of encoding the attribute name "who" as
| <td valign="top">
| forcing CSS to use large selectors and overide native HTML, it
| should be something simple like
| <td class="attrName">who</td>
| with the CSS controling alignment, boldface, and fixed font). (And
| yes, I realize a lot of it is already done genericly.)
| * Classes that have no members should be supressed.
| * There should be a table of contents with links to "Classes",
| "Elements", and "Macros", and also to <div>s up to a certain level
| of nesting.
| * There should be a large, obvious divider between the "Classes",
| "Elements", and "Macros" sections.
| * Perhaps there should be a table of contents with links to each and
| every class, element, and macro.
| * The global attributes should be listed in each element definition
| as a single class reference, rather than individually, unless
| there's a change for a particular element, of course.
| I.e., instead of
| would do, and would be much easier to read.
More information about the tei-council