At 11:15 11/01/2001 +0000, Gervase Markham wrote:
>You do realise that there are something like 10,000 legacy documents on
>mozilla.org you'd have to convert?
Yes I'm not unaware that it would take time to modify existing documents, a
lot of that could be automated for a basic restructuring that could be
further refined later. As further refining is low on the scale of
probability the likelyhood is that the documents will become out of date
and be replaced by documents that are better structured.
>Also, if someone wants to write something and whack it up there, to meet a
>need, they'd be a bit annoyed if they had to send it off to someone to do
>a conversion first. Particularly if that person was on holiday.
So they'll be able to whack it up without any consultation process?
>
> > >2) Low barriers to document contribution
> >
> > Providing plain text seems a very low barrier, far lower than requiring the
> > use of a particular tool.
>
>It isn't, because are used to contributing website content with HTML
>editors.
Ummm you can't have your cake and eat it. You can't say that using
Composer is a barrier to new authors submitting and then say you can't use
the lowest common denominator because you are used to contributing with HTML.
> > After all that is what we have now
> > and the result is a mess, continuing in the same way will only produce a
> > different mess later on.
>
>The mess we have currently is not the fault of the way we mark up the
>content. :-)
Quite a lot of the mess is because its assumed that all a web site is is a
collection of HTML there is no structure that makes sense. Confusing the
submission of content with the delivery of content is a plain and basic
mistake.
> > >It fails all of these. If I suggested to [EMAIL PROTECTED] that what
> > >www.mozilla.org needs is for us to write an entire document-handling
> > >system based around an invented XML dialect for document description,
> > >their reaction would be... interesting.
> >
> > I haven't suggested anything like that and any way I think I've shown that
> > it meets all of the above criteria.
>
>Maybe I've misunderstood your proposal. You want all documents for the
>website to be submitted as, or converted by volunteers to, your XML format
>(or DocBook.) You then want them converted (either on the fly, or
>once-only) to HTML for sending to browsers. You also want to write all the
>necessary site management tools to deal with all this stuff.
The XML I gave was an off the cuff example to explain the kind of
structuring required if you want to achieve a logical structure that allows
documents to be delivered in a variety of ways and at the same time defend
against link rot. DocBook is an existing way of doing the same thing, its
learning curve is a little steeper than a simpler XML dialect which is why
I used an example dialect to illustrate the kind of process needed. But
that's what it was, an illustration.
Using either DocBook or XML does not preclude using HTML (I just think HTML
a god awful way of submitting content its the wrong tool for the job), I
was emphasising that the barrier to submission is constraining authors to
any format other than plain text. Constraining submissions to a particular
tool is going to reduce the number of authors still further, not increase them.
>Furthermore, you want us to throw away any possibilities of using any of
>the myriad of currently-written tools, such as search indexers, that work
>with HTML content. We also can't use a database because, again, they are
>all based around the idea that you use HTML.
Bollocks. Indexers such as LXR don't care about syntax, there are plenty
of indexers that don't care about the format of what is indexed, exclusion
syntax isn't very complicated. Thinking that a database cares about HTML
is asinine it could just as easily use XML, XML to database storage is
_simple_ that's part of the point of XML.
I can accept a great many objections as being valid, inserting a structural
markup step for instance might seem to make the process lengthier and more
tortuous but if you are constraining to HTML Strict you have that step
anyway. What I think is unacceptable is NIH as a reason for not
considering something.
Other than a parser, and DocBook doesn't require that, nothing I've
suggested requires the use of outlandish tools, it isn't reinventing wheels
its using wheels to build a better carriage.
> > You might think it entirely pointless
> > but as other documentation projects solve the same problems in similar
> > ways,
>
>The mozilla.org website is not (except in some parts) a documentation
>project in the same way that linuxdoc.org is. If you ask them, I very much
>doubt they have their website pages originally written as anything other
>than some form of HTML.
So Mozilla is never going to have documentation that end users and
distributors can use because its more important to do a web site?
I'm not one to flog dead horses, even if they are throroughbreds, so unless
anyone has any observations on it that take it forward I'll drop it
completely. :-)
Simon
>Gerv
===============================================
The more exotic the Project name the more ordinary the Product
S.P.L.
