[tei-council] TEI next release

[Syd Bauman]

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
SR> life.

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
[path-to-Sourceforge:/svnroot/tei/trunk]/Stylesheets/release/tei-xsl/p5
or
[path-to-website]/release/xml/tei/stylesheet
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:
| >>
|    id716662:zeroOrMore
|    [
|       rng:choice
|       [
|          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.)


Below
-----
| 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
| importance.
| 
| * HTML needs to be generic, placed under CSS control (e.g., instead
|   of encoding the attribute name "who" as
|   <td valign="top">
|     <tt>
|       <b>who</b>
|     </tt>
|   </td>
|   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
|      att.global.attribute.xmlid,
|      att.global.attribute.n,
|      att.global.attribute.xmllang,
|      att.global.attribute.rend,
|      att.global.linking.attribute.corresp,
|      att.global.linking.attribute.synch,
|      att.global.linking.attribute.sameAs,
|      att.global.linking.attribute.copyOf,
|      att.global.linking.attribute.next,
|      att.global.linking.attribute.prev,
|      att.global.linking.attribute.exclude,
|      att.global.linking.attribute.select,
|  only
|      att.global.attributes,
|      att.global.linking.attributes,
|  would do, and would be much easier to read.