[tei-council] some formatting thoughts -- reference documentation

[Syd Bauman]

> I see what you mean; but I have to say, I take the contrary view,
> viz that the formatted HTML Guidelines are part of the release;
> when someone downloads the packages on 1st December or 1st
> February, I expect (DV) the HTML they install locally to look the
> same as TEI web site.

I don't know what the "(DV)" means, but otherwise I don't disagree --
I could easily see keeping the live website in step with the
downloaded release package (as opposed to the development HEAD in
SF). But more importantly, I don't think that process of updating the
formatting (and thus the release package) should be driven by
updating the Guidelines to 1.1. I think it should be driven by
whenever the formatting has improved. (I don't know for sure what
flexibility SF's versioning number system gives us, and almost don't
care -- SF should not dictate our practice. But don't we have the
possibility of more fine-grained releases? E.g., 1.0.1 for fixes to
the Guidelines, 1.0.1.1 or 1.0.1_F2 for formatting improvements?)


> I suggest that when release 1.0 is done, you can start work on a
> 1.1 branch, which includes changes to guidelines.xsl which makes
> the HTML, and make it available under its own terms.

This does not make sense to me. Why would we make a "1.1" branch,
rather than continue to develop in the current branch? (I agree
wholeheartedly that we should create a "release-1.0" tag on 11-01, to
make it easy to grab that snapshot.)


> > Again, formatting is pretty disjoint from content.
> I agree, it is not the same thing. But, to me, its part of the
> package.

I suppose you could pretty easily convince me of that, but it doesn't
follow that formatting should be frozen.


> as ever, my views are those of the hard-line project manager; we
> should set deadlines for tasks, and stick to them.

Alright -- but what has that got to do with whether or not we freeze
formatting at 1.0?


> sorry, confused. do you mean we need headings only for the non-JS
> case, or always?

In all cases. In fact, we even need it for individual letters,
actually. Otherwise user goes to REF-CLASSES-MODEL.html, clicks on
"k", and nothing happens ... she clicks on "j", nothing happens ...
"u", "v", "w" ... she gives up in disgust and reverts to using MS
Word. 


> with the best will in the world, I am willing to bet something
> changes in the P5/ tree on 31st October......:-} but yes, we should
> definitely have implemented any formatting decisions by 21st.

I agree completely, but really really don't think we should plan on
it :-)