At 11:51 08/01/2001 +0000, James Green wrote:
Simon P. Lucy wrote:

At 00:20 08/01/2001 +0000, James Green wrote:

[ snip ]

There already are gateways for cvs available with and without secure access.

Good. What we need is something that can work within the mozilla.org setup. Those who want to see this happen, email [EMAIL PROTECTED] who's interested in seeing such a thing, and keep the rest of us informed of your progress/outcome. It will be interesting to see if this actually results in something that gets used heavily or not.

There is a project on Sourceforge with a web client for CVS I've emailed the owner of the project.

<delenda est...>


Putting a little more context into what she was saying, I believe the problem was getting the document authors (of which many are outside contributors) to all use the same thing. Getting them all to use Composer is not easy (choice of editor is a very personal thing), but getting them all to use DocBook would be nigh-on impossible, at least initially.

If initial work were done on getting the site into DocBook format, and a mechanism found that kept everything up-to-date, even getting authors tp use DocBook, that wasn't time consuming and doesn't involve everyone using special software that may or may not run in their environment, then there's a possibility that all authors could See The Light and start *wanting* to use DocBook. Of course, if everybody did use DocBook, how would new contributors get involved?

Like I said, I'm not throwing the idea out of the window, but afaict Dawn shares my opinion that DocBook isn't implementable since the authors would have to change their ways too much. If a middle-layer army of convertors was available to do html->docbook conversion then it too would have to prove that it could work in a timely and accurate manner that didn't piss the authors off. Remember, authors expect their work to be put on line, not converted into DocBook and lose or change presentational effects.

Well in this regard the authors have very little say in terms of the presentational effects.  They are providing content not layout.  This is what I mean by conflating the submission of content and the delivery of that content.  The website should have a fairly fixed and generic layout form, other than effects of emphasis, italics, bold etc, the author has no need to consider the way the content is laid out.

This is much like a magazine where the editor and compositors flow and layout text and pictures and the authors provide copy.  Editors of magazines are more than happy to get plain text that they can then layout to their hearts content. (umm pun not intended :-))

The worst position I can see is for everyone to submit their own carefully honed HTML and then try and squidge that into some kind of shape.  If the authors can indicate logical content by some means (whether that's DocBook or something less I really don't care), then all the better but it isn't necessary that can be done by someone else.  I certainly wouldn't mind structuring plain text, though I wouldn't particularly want to hack about with HTML laid out text I'd be able to do that as well.  All bearing in mind that there is a structure.

But to carry on without defining a structure to the content is a waste of time.


If there is no codifying of the content then the documentation is still going to be an unholy mess.

You have a better idea? Bring a workable DocBook or alternative solution to the table, and I'm sure we'll be more than happy to look at it. I personally do not like the idea of storing out documentation in HTML either, it present many archectural problems, but until everyone who produces the documentation is happy to change the system, it stays (imo).

Sure, only accept plain text or structured text to whatever form that's agreed.  Plain text can be simply laid out with a template regardless of whether any structure is applied to it previously or not.  Once decided on (whether its DocBook or anything else), that can be applied to the plain text.

That's not to say there aren't still difficulties, tabular information for instance is a pig to define in just text since it relies on using delimiters, but then again the prettiness of the content isn't relevant for the submission.  There would need to be some understanding as to what constitutes a paragraph and a page and if graphics were included then written instructions would have to be attached to the plain text in a separate file.

None of that is pretty but it is manageable, allowing chaos at the time of submission though isn't.

Simon

James Green



 Beware knowledge cheaply gained for in the spending of it you may pay more than its worth.
 S. P. Lucy

Reply via email to