> 1). Those people who would like to see us use some form of cvs gateway
> for those who don't have cvs or don't know how to use it can contribute
> to the site, well you guys bring it to the table in a demonstratable
> form, and we'll all take a look. 
<snip>

That's all very well, but we are deciding things in the wrong order. If,
for example, we decide to use Zope to manage the site (which is quite
possible - [EMAIL PROTECTED] have a good relationship with the Zope
people, and we may well be able to get them to lend us a Zope guru. Also,
it solves a great deal of the problems we are looking at, including ease
of update, in one go) then this problem goes away.

> 2) The above also goes for the SGML/DocBook people. I just spoke to Dawn

This is _so_ out of the question, it's untrue :-) There is no way that you
will get all the contributors to a website of this size to work in these
formats; and anyway, it's very bad form for an organization dedicated to
the promotion of web technologies to then claim they are unsuitable for
its website source.

> 3) If you are one of those who believes firmly that using a database to
> serve up the content, then you make a nice, quick-to-use interface, and
> we'll take a look. If it's that quick to use, it should be no problem
> with moving our work out of files and into the database, right? Again,
> this should be interested parties only.

Again, I think this is the wrong way to look at it. Either a (specified)
database solution is the right way to go, or not. If it is, we should all
work towards that end. If it isn't, no-one should be spending time
prototyping. If we can't all agree on what site management solution to use
(with homebrew being an option) then we may have to have a vote, or ask
staff@ for a final verdict.
 
> 4) Am I right in thinking that XHTML1.0 and HTML 4.01 Strict are roughly
> the same, at least in terms of code used and end result in browsers? If
> so, we need to settle on one or the other.

No, absolutely not - particularly where Mozilla is concerned. See Henri's
comments - XHTML, served as application/xml, is passed through the XML
parser. HTML of any form goes through the HTML parser. 

Regarding Matthew's earlier comments, which I can't find, it would be
_very_ _bad_ to use XHTML and serve it as text/html - without enforcing
the well-formedness constraint on XHTML from the very start, you are
throwing away the world's best chance to have a HTML-esque format which is
zero-cruft, and can be understood by lightweight parsers which don't need
to deal with broken code.

> 6) We need to settle on filesystem layout and URI layouts. Some have
> been suggested, I'm not aware of anything we should be working to. It's
> make our minds up time.

Again, this problem goes away if we use a content management system. More
important is the navigational layout, which is a separate thing which
keeps getting conflated with the filesystem layout and even the URI
layout.

> Oh, and apparently we must work well on Nav 4.x on Solaris. So Dawn says.

If it works on Nav 4.x on any platform, it should work on the others -
right?

Gerv

Reply via email to