Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

[sorry for cross-post: this is a general issue, but I'd like the cocoon
people to know what I'm doing so that they might give me a hand :)]

I started the effort that will, hopefully, bring us a much more useful
documentation system for xml.apache.org and, hopefully, to the entire
ASF, even if political and ego obstacles will get in the way.

I personally don't care: this effort is mainly to create a better
documentation infrastructure following the goals outlined below. I
started the Cocoon project three years ago exactly for this reason and
now that has all the features I needed, I think I can attack the problem
from a very wide angle. 

The site building system will be targetted toward xml.apache.org, but
I'll keep a very broad perspective, making it possible to adapt the
system to other apache.org projects with very few changes.

BIG DISCLAIMER: however, whether this happens or not, I personally don't
care. For sure, don't count on me wasting my time on fighting about 'my
DTD is better than yours' or 'my system is
faster/smaller/cleaner/easier-to-use/more-extensible than yours'.

I'll come up with a system that works and then you guys will vote on
what to do. I consider this an exercise to present full Cocoon
potentials (that, objectively, beat the pants out of all the other
systems used around Apache) but nothing more than this.

                                    - o -

Ok, now that I stated this, let's get into the effort goals.

GOALS
-----

1) Speed: current xml.apache.org is slow. Empirical studies on learning
processes indicate that if a page takes more than 10 seconds on a 56Kbs
modem, the cognitive experience is degrated.

2) Coherence: current xml.apache.org is extremely incoherent. Again,
it's easy to understand that lack of coherence between subprojects docs
is perceived (and sometimes reflects!) lack of cooperation.

3) Navigation: the navigation experience on current xml.apache.org is a
nightmare. There is no way to perceive the basic elements of spatial
navigation: where am I? where can I go? how do I go back? how do I go
there?

4) Depth: the current xml.apache.org page layout forces a flat hierarchy
of levels. The current Cocoon documentation somewhat extends this, but
the visual look doesn't reflect the notion. Visual codes are extremely
important to allow a easy and immediate navigation even at the deepest
level.

5) Usefulness: xml.apache.org contains powerful software but it's not
powerful in itself. It should be a window on the information useful for
both users and developers, along with friendly behavior, such as
print-friendly versions of the single pages and of the whole
per-subproject documentation, pagination of long articles,
site-restricted search, graphs of project-related data and so on.

6) Simplicity: xml.apache.org is done by volunteers, on all levels.
Nobody is directly paid to do this. Not even myself. So, if the above
goals are met, but the system is not simple and immediate to use for
those who have to maintain and update the information, the result is
void over a short period of time.

7) Extensibility, Flexibility, Modularity: web sites, just as software,
are living entities that adapt on their environment. The build system
must not restrict the ability to evolutionary extend the information
architecture.

8) URI Solidity and Future Compatibility: URIs are contracts between the
publisher and the user. Human users have the ability to estimate the
long-term validity of these contracts and 'route around' eventual broken
links, while machine users do not. The goal is to come up with a system
that allows to generate a web site with strong URIs.


Design Decisions
----------------

staticity: even if I think that the availability of a dynamic publishing
system would be beneficial, considering the web site load, the load of
the apache machines and the state of the JVM for FreeBSD and the
political problems behind all this, it's *must* easier (at least for
now) to have a static version of the site batch-produced and then placed
into the web-serving space.

automaticity: the site will be automatically generated out of files
stored into CVS. The idea is to have GUMP-like nagging features that
send email to the various mail lists using XML validation to estimate
the 'integrity' of the docs placed.

For this reason, in honor of Sam Ruby's great work, and for the
resonation with 'forest', thus a huge number of trees (i.e. XML files),
I call this effort "Forrest".

I believe that together, Forrest and Gump, will help bringing apache
quality one step up (moreover, as in the name, forrest wraps gump and
will publish its generated data, providing more overall coherence)

                                        - o -

separation of concerns
----------------------

There are three concern islands, here is a list of their duties.

subproject
==========

each subproject should provide:

3.a) a 'description' file that includes information on the codebase, its
description, its released versions, its CVS modules, its CVS tags, its
mail lists and its documentations (yes, a subproject might have more
than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
[proposed filename: /description.xml]
 
3.b) a 'committers info' file that includes information on the
committers, along with a short bio, an email address and a picture of
them. [proposed filename: /committers.xml]

3.c) a 'change log' file that includes information on changes and
software relases [proposed filename: /changes.xml]

3.d) a 'todo list' file that includes the information on things to do
and who volunteered for doing it [proposed filename: /todo.xml]

3.e) a 'news' file that includes events and useful information that
should be made available to the general public.

then, for each documentation (location is get from the description
file):

3.f) a 'table of content' that indicates the hierarchical sequence of
the files and where to find them into the CVS repository (for each
documentation). This is kept as a single file to allow document writers
to maintain 'coherence' and visualize the entire part. This is
equivalent to the stylebook book.xml file but with full nesting
capabilities.

3.e) the pages that componse the documentation (their location is get
from the ToC file)

Log scanner
===========

The log scanner is a set of scripts that scan the logs from the CVS, the
mail lists and the web site to gather information on:

 1) mail list activity (subscribers and messages)
 2) web site activity (hits and downloads)
 3) CVS activity (general commits, commits per person)

This scanner provides this information in a simple format that can be
easily fed into the documentation building system.

Build system
============

The build system will:

1) aggregate, filter and otherwise adapt the information collected from
the various subprojects CVS modules, from the log scanner and from the
GUMP run into static HTML files (for the browser pages), static PDF
files (for print-friendly versions) and JPEG images (for graphs).

2) generate navigation information in all the pages

3) check validation of all the required XML files and send nag messages
to the mail lists if failure occurs.

4) generate httpd-related corollary files (.htaccess, header.html,
footer.html and so on).

5) upload the parts that didn't have failures online.

The goal is to have the system running completely autonomous: this
follows the Gump approach. [Sam, I'll need your help here, since I don't
have an account on nagoya]

                                        - o -

Things to decide
================

1) DTDs
-------

The Cocoon project already has DTDs for 'documentation','change
logs','todo list' and 'specifications'. They mainly use XHTML tags and
are very easy to learn (they are an expansion of the original stylebook
DTDs, so it's pretty easy to automatically adapt existing stylebook
documents to this improved DTD, still keeping the simplicity we had
before).

The rest of the required DTDs (description, news and ToC) must be agreed
upon (i'll work on them in the next days)

2) URIs
-------

In order to achieve the future-compatible goal, we must come up with a
guideline for URIs.

For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
into /cocoon1, creating a shit-load of broken links.

Two solutions where proposed (add your own if you have more)

 a) use version specific information and use mod_rewrite to adapt. for
example

 xml.apache.org/cocoon/1.8.2/index.html
 xml.apache.org/cocoon/2.0b1/index.html
 xml.apache.org/cocoon/2.0b2/index.html
 xml.apache.org/cocoon/2.0rc1/index.html
 xml.apache.org/cocoon/2.0rc2/index.html
 xml.apache.org/cocoon/2.0/index.html

then

 xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml

Problem is that while those versioned URI are never broken, the
version-less redirected URI is changed for each release and doesn't
reduce broken links. Also, it's probably easier to download the required
version and look into the shipped docs and results in unnecessary big
web sites.

 b) use semantic-meaningful yet version-less URIs

  xml.apache.org/cocoon/previous/ -> points to the previous generation
docs
  xml.apache.org/cocoon/ -> points to the latest docs
  xml.apache.org/cocoon/next/ -> points to the next generation docs

which removes the need to have keep all the docs versions online, yet
provides the ability to have both versions the latest one and the
previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
Cocoon 2.1-dev today). 

The problem of broken links isn't solved since everytime there is a
transition, there is a chance of breaking previously established links
if the docs ToC changes from one generation to the next.

3) layout
---------

The layout previously proposed on this list was a solution to the speed
problem but I couldn't adapt it to the depth needs identified in the
rest of the goals.

So, I resurrected my rusty web design skills and came up with the layout
you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
win2k. 

Feedback, suggestions and criticisms are appreciated.

4) CVS location and mail list discussions
-----------------------------------------

Just like Gump which is not a subproject on its own, Forrest doesn't
deserve that status neither as long as it remains a single-man show (and
my experience tells me it will very likely remain so if the above goals
are met)

At the same time, just like Gump, it requires a CVS space.

Possible places are:

 1) xml-site
 2) xml-forrest
 3) xml-site2

for mail list discussions, solutions are:

 1) general@xml.apache.org
 2) cocoon-dev@xml.apache.org
 3) site@xml.apache.org
 4) forrest@xml.apache.org

Please, add your comments/suggestions and your votes where a decision is
required.

Thank you.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

David Crossley wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
> 
> This is really great that you have taken this on Stefano,
> many thanks. We will all help where we can.

Thanks.

> I used "View source" to look behind-the-scenes and i see
> that there are still tables embedded within tables embedded
> within other tables. 

Look again: I used only two table nested, one for the sitebar area and
one for the content area. The other tables on top are sequential, thus
very light.

> I think that this will again lead to troubles
> on some browsers with the larger documents.

I know, that's where pagination should kick in.
 
> I realise that there may be a need to use one table to achieve
> the left-hand columns. However, i would like us to minimise the
> need for embedded tables, especially in the main text panel.

I'll try to use CSS2 properties and <div> sections for the sitebar, but
I'm not sure if I can get the same portability.

Anyway, thanks for your suggestions, keep them flowing. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

David Crossley wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
> 
> This is really great that you have taken this on Stefano,
> many thanks. We will all help where we can.

Thanks.

> I used "View source" to look behind-the-scenes and i see
> that there are still tables embedded within tables embedded
> within other tables. 

Look again: I used only two table nested, one for the sitebar area and
one for the content area. The other tables on top are sequential, thus
very light.

> I think that this will again lead to troubles
> on some browsers with the larger documents.

I know, that's where pagination should kick in.
 
> I realise that there may be a need to use one table to achieve
> the left-hand columns. However, i would like us to minimise the
> need for embedded tables, especially in the main text panel.

I'll try to use CSS2 properties and <div> sections for the sitebar, but
I'm not sure if I can get the same portability.

Anyway, thanks for your suggestions, keep them flowing. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Mikhail Fedotov <mi...@kittown.com>]

Hi!

> Instead of working round crappy browsers, shouldn't we
> tell the user how crappy their browser is?

If your web page is standards-conformant but looks terrible
 in old browser while others are looking good, then BOTH
 your page and that browser are wrong.

That is more useful for you, to make you page more
 accessible, or to sacrifice part of your audience in an
 attempt to make world better (or lower costs) ?

This is the only one real question.

Mikhail

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Nicola Ken Barozzi <ba...@nicolaken.com>]

----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>; "Apache XML" <ge...@xml.apache.org>
Sent: Wednesday, December 19, 2001 3:19 PM
Subject: Re: [OT] Design Rant


> Copied to general@ since this is a general discussion.
>
> Ugo Cei wrote:
> >

<snip/>

> > Incidentally, adopting a pure-CSS based solution for both layout AND
> > styling means that people using:
> >
> > - text browsers
> > - screen readers for the sight impaired
> > - mobile devices
> > - anything you cannot conceive now but that will be make web
> >    access available from your washing machine or whatever :)
> >
> > will be able to access the site contents without their "screen" or
> > reader being cluttered with spurious markup that is not in any way
> > related to the content they need.

I like and agree on all you say, except that there is a real-world problem.
Netscape4 -crashes- with CSS set on the body tag.
@see http://www.alistapart.com/stories/died/
Not nice.  :-(

Here is part of the article:
<article type="part" url="http://www.alistapart.com/stories/died/">
An actor never says to the crowd, "I'm a little old for this role, wouldn't
you say, folks?" And a Web designer never tells the viewer, "Whew! You
should see all the JavaScript I've put in the header to protect you from
realizing how crappy your browser is."

It is gauche to tell users that their browser stinks. It's like insulting
their clothing or their charming regional accent.

It's unfashionable to complain about a specific browser, though it's become
acceptable (as it should be) to complain about a general lack of support for
standards.

Yet, if information wants to be free, so does the truth.

I don't know about your shop, but in mine, we spend hours spewing out
torturous (often questionable) code to make stuff work in Navigator 4.

"Netscape and Style Sheets. They go together like peanut butter and bicycle
chains," I confided to a fellow Web designer recently.

It's become the dirty little secret of our Industry. The thing nobody wants
to say out loud.

</article>

Instead of working round crappy browsers, shouldn't we tell
the user how crappy their browser is?
How can market dynamics work if the user is unable to see
how really good a product is, and for "good" on the Web it
should be also "follows the standard".
If the browser isn't capable of performing sensibly on an old
and stable web standard, is it my fault?
Let the producer fix it.
I'm not sure that this is really the way to go, but it sure seems
sensible to me.

Nicola Ken Barozzi These are the days of miracle and wonder...
                                ...so don't cry baby, don't cry
<xm...@nicolaken.com>                          Paul Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Martin Stricker <sh...@gmx.de>]

Stefano Mazzocchi wrote:
> 
> Copied to general@ since this is a general discussion.
> 
> Ugo Cei wrote:

<snip type="not_important"/>

> > Using a CSS-based layout also means that people using 4th generation
> > browsers (NS 4, IE 4, etc.) must be "protected" from such a
> > stylesheet or they will see utter garbage. Hiding the CSS from them
> > means that they won't be able to appreciate the layout, but will
> > nonetheless be able to read the full *content*, just not very well
> > styled. But come on, this is a site devoted to *developers*
> > developing for the Web. Can you imagine a web developer today using
> > ONLY NS4 or IE4?
> >
> > Incidentally, adopting a pure-CSS based solution for both layout AND
> > styling means that people using:
> >
> > - text browsers
> > - screen readers for the sight impaired
> > - mobile devices
> > - anything you cannot conceive now but that will be make web
> >    access available from your washing machine or whatever :)
> >
> > will be able to access the site contents without their "screen" or
> > reader being cluttered with spurious markup that is not in any way
> > related to the content they need.

> > In other words, what I am proposing is that we stop worrying about
> > being bacward compatible in order to accomodate old, buggy and
> > non-compliant user agents, but instead start to be FORWARD
> > compatible in order to accomodate FUTURE standard-compliant user
> > agents.
> >
> > Let me know what you think about it and sorry for being slightly OT.

> Moreover, this is a site dedicated to new technologies for the web and
> a site dedicated to evangelize open standard compliance thru reference
> implementations and cooperation.
> 
> If we page a page on the 'about' section that talks about our reasons,
> I think people might even appreciate our effort to both evangelize the
> technology and 'put in practice' what we say.
> 
> What do others think? (we must have a wide agreement to go forward on
> this)

Usually I always say KISS (keep it simple, sweetie) and "keep an eye for
older and text browsers" to web designers. Particularly text browsers
since I'm often working on *nix in text mode. Since the CSS-only design
will work at least somehow on all these (which nested tables don't do)
I'll give it a provisional
+1
(though I'm not a committer but a regular guest on the site)
When the new CSS-design is teady I'd like to test it in various browsers
so I can find any difficulties. Just put it up somewhere on the web,
ideally together with Stefano's Forrest proposal and the current
xml.apache.org design for broad testing.

giacomo@apache.org wrote:
> I know of manager visiting the sites to verify we told them the truth
> about open source, licensing, cool projects when we do evangelize OS
> products to them.
> 
> Those people are not on the edge of the technology (read use
> IE6/NS6.2/Mozilla browsers). They have corporate PCs with the software
> someone else has installed there and they usually are not able to
> change that.
> 
> I don't want to say we shouldn't go the CSS way, but we might not be
> able in all cases to show our cool sites (in terms of technology used)
> to the ones having something to say in companies where others here
> like to bring in OS software.

That's an important point! We want our software to be used by the
corpararte world. I recommend going on with the CSS approach and then
doing heavy testing and tweaking. If the outcome is "manager-approved"
we go ahead, if not we'll conduct the real vote then when we have all
the facts to decide on.

Best regards,
Martin Stricker
-- 
Homepage: http://www.martin-stricker.de/
Registered Linux user #210635: http://counter.li.org/

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Tim Myers <ph...@stserv.hcf.jhu.edu>]

http://stserv.hcf.jhu.edu/~phantom/div2.html

Here's another one, and i think i discovered something important about css for
layout-- width as a percentage effectively can't be applied to the same element
as border, margin, or padding.  That's because width is the width of the
content... and if you do that in percentage,  adding a pixel here and a pixel
there on the edge goes over the alotment.  I wish the css width would equal
contentwidth+borderwidth+paddingwidth so that padding and border would cut in
on the content width rather than overflowing and making it impossible to
control the left and right side of a box simultaneously without nesting.  Alas
it is not so, i have read the spec--and the spec basically said "too bad."

http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-width

So, my rant about the recent browsers was fairly off base (although 50% width
is still buggy in ie so 49.9 will have to do).  The browsers are doing what
they are supposed to.  to set padding/border within a percentage widthed box,
the padding must be set on a box nested inside the percentage widthed box.
Make sense?

Tim
 
On Wed, Dec 19, 2001 at 10:04:12PM -0500, Tim Myers wrote:
> I've got something along those lines that works in ie5 and mozilla:
> 
> http://stserv.hcf.jhu.edu/~phantom/div.html
> 
> 50% is a funny number.  And so is 100 for that matter.
> The different browsers do very different things with roundoff error.
> 
> I'm not saying how practical it is and i have no idea what opera does to it.
> I wish tables would go away, but i also wish css would render correctly in any browser.
> 
> Tim
> 
> On Wed, Dec 19, 2001 at 02:46:59PM -0800, Robert Koberg wrote:
> > it's pretty, but I did not see anything about the design I was talking
> > about??
> > 
> > ----- Original Message -----
> > From: "Paulo Gaspar" <pa...@krankikom.de>
> > To: <co...@xml.apache.org>
> > Sent: Wednesday, December 19, 2001 12:58 PM
> > Subject: RE: [OT] Design Rant
> > 
> > 
> > > > I really like this type of design and use it for my own stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that??
> > >
> > > I think this article holds the answer to your question, with outer margins
> > > and all:
> > >    http://www.alistapart.com/stories/practicalcss/
> > >
> > >
> > > Have fun,
> > > Paulo Gaspar
> > >
> > > http://www.krankikom.de
> > > http://www.ruhronline.de
> > >
> > >
> > > > -----Original Message-----
> > > > From: Robert Koberg [mailto:rob@koberg.com]
> > > > Sent: Wednesday, December 19, 2001 9:14 PM
> > > > To: general@xml.apache.org
> > > > Cc: cocoon-dev@xml.apache.org
> > > > Subject: Re: [OT] Design Rant
> > > >
> > > >
> > > > I really like this type of design and use it for my own stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that?? If not, I don't know if this
> > > > approach should be evangelized. You are limited to three columns (outer
> > > > columns fixed-width, inner is variable). While I don't have any
> > > > problems, I
> > > > have clients who would.
> > > >
> > > > best,
> > > > -Rob
> > > >
> > > > ...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> I've got something along those lines that works in ie5 and mozilla:
> 
> http://stserv.hcf.jhu.edu/~phantom/div.html
> 
> 50% is a funny number.  And so is 100 for that matter.
> The different browsers do very different things with roundoff error.
> 
> I'm not saying how practical it is and i have no idea what opera does to it.
> I wish tables would go away, but i also wish css would render correctly in any browser.
> 
> Tim
> 
> On Wed, Dec 19, 2001 at 02:46:59PM -0800, Robert Koberg wrote:
> > it's pretty, but I did not see anything about the design I was talking
> > about??
> > 
> > ----- Original Message -----
> > From: "Paulo Gaspar" <pa...@krankikom.de>
> > To: <co...@xml.apache.org>
> > Sent: Wednesday, December 19, 2001 12:58 PM
> > Subject: RE: [OT] Design Rant
> > 
> > 
> > > > I really like this type of design and use it for my own stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that??
> > >
> > > I think this article holds the answer to your question, with outer margins
> > > and all:
> > >    http://www.alistapart.com/stories/practicalcss/
> > >
> > >
> > > Have fun,
> > > Paulo Gaspar
> > >
> > > http://www.krankikom.de
> > > http://www.ruhronline.de
> > >
> > >
> > > > -----Original Message-----
> > > > From: Robert Koberg [mailto:rob@koberg.com]
> > > > Sent: Wednesday, December 19, 2001 9:14 PM
> > > > To: general@xml.apache.org
> > > > Cc: cocoon-dev@xml.apache.org
> > > > Subject: Re: [OT] Design Rant
> > > >
> > > >
> > > > I really like this type of design and use it for my own stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that?? If not, I don't know if this
> > > > approach should be evangelized. You are limited to three columns (outer
> > > > columns fixed-width, inner is variable). While I don't have any
> > > > problems, I
> > > > have clients who would.
> > > >
> > > > best,
> > > > -Rob
> > > >
> > > > ...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Tim Myers <ph...@stserv.hcf.jhu.edu>]

I've got something along those lines that works in ie5 and mozilla:

http://stserv.hcf.jhu.edu/~phantom/div.html

50% is a funny number.  And so is 100 for that matter.
The different browsers do very different things with roundoff error.

I'm not saying how practical it is and i have no idea what opera does to it.
I wish tables would go away, but i also wish css would render correctly in any browser.

Tim

On Wed, Dec 19, 2001 at 02:46:59PM -0800, Robert Koberg wrote:
> it's pretty, but I did not see anything about the design I was talking
> about??
> 
> ----- Original Message -----
> From: "Paulo Gaspar" <pa...@krankikom.de>
> To: <co...@xml.apache.org>
> Sent: Wednesday, December 19, 2001 12:58 PM
> Subject: RE: [OT] Design Rant
> 
> 
> > > I really like this type of design and use it for my own stuff.  The only
> > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > column layout. By that I mean the two outer columns are
> > > fixed-width and the
> > > two+ inner columns are are variable based on window width.
> > >
> > > Hopefully someone knows how to do that??
> >
> > I think this article holds the answer to your question, with outer margins
> > and all:
> >    http://www.alistapart.com/stories/practicalcss/
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
> > http://www.krankikom.de
> > http://www.ruhronline.de
> >
> >
> > > -----Original Message-----
> > > From: Robert Koberg [mailto:rob@koberg.com]
> > > Sent: Wednesday, December 19, 2001 9:14 PM
> > > To: general@xml.apache.org
> > > Cc: cocoon-dev@xml.apache.org
> > > Subject: Re: [OT] Design Rant
> > >
> > >
> > > I really like this type of design and use it for my own stuff.  The only
> > > problem I have (might be ignorance?) is that you can't do a "good" four+
> > > column layout. By that I mean the two outer columns are
> > > fixed-width and the
> > > two+ inner columns are are variable based on window width.
> > >
> > > Hopefully someone knows how to do that?? If not, I don't know if this
> > > approach should be evangelized. You are limited to three columns (outer
> > > columns fixed-width, inner is variable). While I don't have any
> > > problems, I
> > > have clients who would.
> > >
> > > best,
> > > -Rob
> > >
> > > ...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Robert Koberg <ro...@koberg.com>]

I looked again and still don't see it.

can you point it out to me? maybe copy some text so I can search for it?

note: floats won't work for this

...trying to have fun,
-Rob

----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: "Robert Koberg" <ro...@koberg.com>; <co...@xml.apache.org>
Sent: Thursday, December 20, 2001 7:14 AM
Subject: RE: [OT] Design Rant


> As far as I understand, if you browse down trough it they describe
> step by step the CSS principles to do what you asked.
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Robert Koberg [mailto:rob@koberg.com]
> > Sent: Wednesday, December 19, 2001 11:47 PM
> > To: cocoon-dev@xml.apache.org; paulo.gaspar@krankikom.de
> > Subject: Re: [OT] Design Rant
> >
> >
> > it's pretty, but I did not see anything about the design I was talking
> > about??
> >
> > ----- Original Message -----
> > From: "Paulo Gaspar" <pa...@krankikom.de>
> > To: <co...@xml.apache.org>
> > Sent: Wednesday, December 19, 2001 12:58 PM
> > Subject: RE: [OT] Design Rant
> >
> >
> > > > I really like this type of design and use it for my own
> > stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a
> > "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that??
> > >
> > > I think this article holds the answer to your question, with
> > outer margins
> > > and all:
> > >    http://www.alistapart.com/stories/practicalcss/
> > >
> > >
> > > Have fun,
> > > Paulo Gaspar
> > >
> > > http://www.krankikom.de
> > > http://www.ruhronline.de
> > >
> > >
> > > > -----Original Message-----
> > > > From: Robert Koberg [mailto:rob@koberg.com]
> > > > Sent: Wednesday, December 19, 2001 9:14 PM
> > > > To: general@xml.apache.org
> > > > Cc: cocoon-dev@xml.apache.org
> > > > Subject: Re: [OT] Design Rant
> > > >
> > > >
> > > > I really like this type of design and use it for my own
> > stuff.  The only
> > > > problem I have (might be ignorance?) is that you can't do a
> > "good" four+
> > > > column layout. By that I mean the two outer columns are
> > > > fixed-width and the
> > > > two+ inner columns are are variable based on window width.
> > > >
> > > > Hopefully someone knows how to do that?? If not, I don't know if
this
> > > > approach should be evangelized. You are limited to three
> > columns (outer
> > > > columns fixed-width, inner is variable). While I don't have any
> > > > problems, I
> > > > have clients who would.
> > > >
> > > > best,
> > > > -Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [OT] Design Rant

[Paulo Gaspar <pa...@krankikom.de>]

As far as I understand, if you browse down trough it they describe 
step by step the CSS principles to do what you asked.

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]
> Sent: Wednesday, December 19, 2001 11:47 PM
> To: cocoon-dev@xml.apache.org; paulo.gaspar@krankikom.de
> Subject: Re: [OT] Design Rant
> 
> 
> it's pretty, but I did not see anything about the design I was talking
> about??
> 
> ----- Original Message -----
> From: "Paulo Gaspar" <pa...@krankikom.de>
> To: <co...@xml.apache.org>
> Sent: Wednesday, December 19, 2001 12:58 PM
> Subject: RE: [OT] Design Rant
> 
> 
> > > I really like this type of design and use it for my own 
> stuff.  The only
> > > problem I have (might be ignorance?) is that you can't do a 
> "good" four+
> > > column layout. By that I mean the two outer columns are
> > > fixed-width and the
> > > two+ inner columns are are variable based on window width.
> > >
> > > Hopefully someone knows how to do that??
> >
> > I think this article holds the answer to your question, with 
> outer margins
> > and all:
> >    http://www.alistapart.com/stories/practicalcss/
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
> > http://www.krankikom.de
> > http://www.ruhronline.de
> >
> >
> > > -----Original Message-----
> > > From: Robert Koberg [mailto:rob@koberg.com]
> > > Sent: Wednesday, December 19, 2001 9:14 PM
> > > To: general@xml.apache.org
> > > Cc: cocoon-dev@xml.apache.org
> > > Subject: Re: [OT] Design Rant
> > >
> > >
> > > I really like this type of design and use it for my own 
> stuff.  The only
> > > problem I have (might be ignorance?) is that you can't do a 
> "good" four+
> > > column layout. By that I mean the two outer columns are
> > > fixed-width and the
> > > two+ inner columns are are variable based on window width.
> > >
> > > Hopefully someone knows how to do that?? If not, I don't know if this
> > > approach should be evangelized. You are limited to three 
> columns (outer
> > > columns fixed-width, inner is variable). While I don't have any
> > > problems, I
> > > have clients who would.
> > >
> > > best,
> > > -Rob
> > >
> > > ...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Robert Koberg <ro...@koberg.com>]

it's pretty, but I did not see anything about the design I was talking
about??

----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: <co...@xml.apache.org>
Sent: Wednesday, December 19, 2001 12:58 PM
Subject: RE: [OT] Design Rant


> > I really like this type of design and use it for my own stuff.  The only
> > problem I have (might be ignorance?) is that you can't do a "good" four+
> > column layout. By that I mean the two outer columns are
> > fixed-width and the
> > two+ inner columns are are variable based on window width.
> >
> > Hopefully someone knows how to do that??
>
> I think this article holds the answer to your question, with outer margins
> and all:
>    http://www.alistapart.com/stories/practicalcss/
>
>
> Have fun,
> Paulo Gaspar
>
> http://www.krankikom.de
> http://www.ruhronline.de
>
>
> > -----Original Message-----
> > From: Robert Koberg [mailto:rob@koberg.com]
> > Sent: Wednesday, December 19, 2001 9:14 PM
> > To: general@xml.apache.org
> > Cc: cocoon-dev@xml.apache.org
> > Subject: Re: [OT] Design Rant
> >
> >
> > I really like this type of design and use it for my own stuff.  The only
> > problem I have (might be ignorance?) is that you can't do a "good" four+
> > column layout. By that I mean the two outer columns are
> > fixed-width and the
> > two+ inner columns are are variable based on window width.
> >
> > Hopefully someone knows how to do that?? If not, I don't know if this
> > approach should be evangelized. You are limited to three columns (outer
> > columns fixed-width, inner is variable). While I don't have any
> > problems, I
> > have clients who would.
> >
> > best,
> > -Rob
> >
> > ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [OT] Design Rant

[Paulo Gaspar <pa...@krankikom.de>]

> I really like this type of design and use it for my own stuff.  The only
> problem I have (might be ignorance?) is that you can't do a "good" four+
> column layout. By that I mean the two outer columns are 
> fixed-width and the
> two+ inner columns are are variable based on window width.
> 
> Hopefully someone knows how to do that?? 

I think this article holds the answer to your question, with outer margins 
and all:
   http://www.alistapart.com/stories/practicalcss/


Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de


> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]
> Sent: Wednesday, December 19, 2001 9:14 PM
> To: general@xml.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: [OT] Design Rant
> 
> 
> I really like this type of design and use it for my own stuff.  The only
> problem I have (might be ignorance?) is that you can't do a "good" four+
> column layout. By that I mean the two outer columns are 
> fixed-width and the
> two+ inner columns are are variable based on window width.
> 
> Hopefully someone knows how to do that?? If not, I don't know if this
> approach should be evangelized. You are limited to three columns (outer
> columns fixed-width, inner is variable). While I don't have any 
> problems, I
> have clients who would.
> 
> best,
> -Rob
> 
> ...

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [OT] Design Rant

[Paulo Gaspar <pa...@krankikom.de>]

> I really like this type of design and use it for my own stuff.  The only
> problem I have (might be ignorance?) is that you can't do a "good" four+
> column layout. By that I mean the two outer columns are 
> fixed-width and the
> two+ inner columns are are variable based on window width.
> 
> Hopefully someone knows how to do that?? 

I think this article holds the answer to your question, with outer margins 
and all:
   http://www.alistapart.com/stories/practicalcss/


Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de


> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]
> Sent: Wednesday, December 19, 2001 9:14 PM
> To: general@xml.apache.org
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: [OT] Design Rant
> 
> 
> I really like this type of design and use it for my own stuff.  The only
> problem I have (might be ignorance?) is that you can't do a "good" four+
> column layout. By that I mean the two outer columns are 
> fixed-width and the
> two+ inner columns are are variable based on window width.
> 
> Hopefully someone knows how to do that?? If not, I don't know if this
> approach should be evangelized. You are limited to three columns (outer
> columns fixed-width, inner is variable). While I don't have any 
> problems, I
> have clients who would.
> 
> best,
> -Rob
> 
> ...

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Robert Koberg <ro...@koberg.com>]

I really like this type of design and use it for my own stuff.  The only
problem I have (might be ignorance?) is that you can't do a "good" four+
column layout. By that I mean the two outer columns are fixed-width and the
two+ inner columns are are variable based on window width.

Hopefully someone knows how to do that?? If not, I don't know if this
approach should be evangelized. You are limited to three columns (outer
columns fixed-width, inner is variable). While I don't have any problems, I
have clients who would.

best,
-Rob


> >
> > What do others think? (we must have a wide agreement to go forward on
> > this)
>
>
> +1
>
> It produces faster pages, and is easier to work with!
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Robert Koberg <ro...@koberg.com>]

I really like this type of design and use it for my own stuff.  The only
problem I have (might be ignorance?) is that you can't do a "good" four+
column layout. By that I mean the two outer columns are fixed-width and the
two+ inner columns are are variable based on window width.

Hopefully someone knows how to do that?? If not, I don't know if this
approach should be evangelized. You are limited to three columns (outer
columns fixed-width, inner is variable). While I don't have any problems, I
have clients who would.

best,
-Rob


> >
> > What do others think? (we must have a wide agreement to go forward on
> > this)
>
>
> +1
>
> It produces faster pages, and is easier to work with!
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [OT] Design Rant

[Gerhard Froehlich <g-...@gmx.de>]

>-----Original Message-----
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>Sent: Wednesday, December 19, 2001 7:01 PM
>To: general@xml.apache.org
>Cc: cocoon-dev@xml.apache.org
>Subject: Re: [OT] Design Rant
>
>
>Stefano Mazzocchi wrote:
>
>> Copied to general@ since this is a general discussion.
>> 
>> It's a strong position but, hey, I find resonating with what you're
>> saying :)
>> 
>> We have the *luxury* to know what our user base is and estimate their
>> needs very precisely.
>> 
>> Moreover, this is a site dedicated to new technologies for the web and a
>> site dedicated to evangelize open standard compliance thru reference
>> implementations and cooperation.
>> 
>> If we page a page on the 'about' section that talks about our reasons, I
>> think people might even appreciate our effort to both evangelize the
>> technology and 'put in practice' what we say.
>> 
>> What do others think? (we must have a wide agreement to go forward on
>> this)
>
>
>+1
+1, of course

  Gerhard
 
"Sorry, but my karma just ran over your dogma."


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:

> Copied to general@ since this is a general discussion.
> 
> It's a strong position but, hey, I find resonating with what you're
> saying :)
> 
> We have the *luxury* to know what our user base is and estimate their
> needs very precisely.
> 
> Moreover, this is a site dedicated to new technologies for the web and a
> site dedicated to evangelize open standard compliance thru reference
> implementations and cooperation.
> 
> If we page a page on the 'about' section that talks about our reasons, I
> think people might even appreciate our effort to both evangelize the
> technology and 'put in practice' what we say.
> 
> What do others think? (we must have a wide agreement to go forward on
> this)


+1

It produces faster pages, and is easier to work with!


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:

> Copied to general@ since this is a general discussion.
> 
> It's a strong position but, hey, I find resonating with what you're
> saying :)
> 
> We have the *luxury* to know what our user base is and estimate their
> needs very precisely.
> 
> Moreover, this is a site dedicated to new technologies for the web and a
> site dedicated to evangelize open standard compliance thru reference
> implementations and cooperation.
> 
> If we page a page on the 'about' section that talks about our reasons, I
> think people might even appreciate our effort to both evangelize the
> technology and 'put in practice' what we say.
> 
> What do others think? (we must have a wide agreement to go forward on
> this)


+1

It produces faster pages, and is easier to work with!


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

["Kevin A. Burton" <bu...@openprivacy.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefano Mazzocchi <st...@apache.org> writes:

> Copied to general@ since this is a general discussion.
> 
> Ugo Cei wrote:
> > 
> > giacomo wrote:
> > 
<snip>

> > Using a CSS-based layout also means that people using 4th generation
> > browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet or
> > they will see utter garbage. Hiding the CSS from them means that they won't
> > be able to appreciate the layout, but will nonetheless be able to read the
> > full *content*, just not very well styled. But come on, this is a site
> > devoted to *developers* developing for the Web. Can you imagine a web
> > developer today using ONLY NS4 or IE4?

OK.   Some day we are going to have to tell these people to "upgrade".

NS4 is about 4 years old now.  IE4 is about the same.  I think it is acceptable
to tell them to go to hell :)

CSS2 is way too cool to not support :)
<snip>

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - burtonator@jabber.org,  Web - http://relativity.yi.org/

The philosophy of this column is simple: if you have good language skills, you
will be respected and admired; whereas if you clearly have no clue about grammar
or vocabulary, you could become president of the United States.
  --Dave Barry, writing in the Miami Herald.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE8IR53AwM6xb2dfE0RAo00AJ9HLsZ7cHqwFWsRnL6yEIVys23htACgiHUi
bqBa+A+HZw40rgIaBhfiRRU=
=yeIm
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Matt Sergeant <ma...@sergeant.org>]

On Thu, 20 Dec 2001, Michael Hartle wrote:

> David Crossley wrote:
>
> >I was wondering this too - we need to use Cocoon's own
> >capabilities to solve these very real issues. There was a
> >thread on this, but it went quiet. The discussion came around
> >to "why is Cocoon not generating the content on the
> >xml.apache.org/cocoon/ site".
> > [Vote] Improving Cocoon Site
> >http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100765145112325&w=2
> >
> Well, I'd +1 it, if I was allowed to vote. For obvious reasons like
> showing off the capabilities of Cocoon in a consistent, aesthetic way
> and not educating people by force, I consider adapting the web content
> to the browsers of visitors superior compared to any technological
> evangelism.

The Apache servers run on FreeBSD, and changing that isn't going to
happen, and FreeBSD doesn't run Java too well (that's the argument I heard
anyway). One way to do it would be to use mod_proxy or something, to proxy
all content to a new server somewhere else. But then it'll be even slower.

Or run AxKit, which runs fine on FreeBSD, but kinda defeats the point :-)

-- 
<!-- Matt -->
<:->Get a smart net</:->


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Michael Hartle <mh...@hartle-klug.com>]

David Crossley wrote:

>I was wondering this too - we need to use Cocoon's own
>capabilities to solve these very real issues. There was a
>thread on this, but it went quiet. The discussion came around
>to "why is Cocoon not generating the content on the
>xml.apache.org/cocoon/ site".
> [Vote] Improving Cocoon Site
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100765145112325&w=2
>
Well, I'd +1 it, if I was allowed to vote. For obvious reasons like 
showing off the capabilities of Cocoon in a consistent, aesthetic way 
and not educating people by force, I consider adapting the web content 
to the browsers of visitors superior compared to any technological 
evangelism.

Best regards,

Michael Hartle,
Hartle & Klug GbR


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[David Crossley <cr...@indexgeo.com.au>]

John Morrison wrote:
> <snip/>
> >  Ugo Cei wrote:
> > > In other words, what I am proposing is that we stop worrying about being
> > > bacward compatible in order to accomodate old, buggy and non-compliant
> > > user agents, but instead start to be FORWARD compatible in order to
> > > accomodate FUTURE standard-compliant user agents.
> > >
> > > Let me know what you think about it and sorry for being slightly OT.
> 
> If we are using a live Cocoon then we can select different views
> based on the browser no?
> J.

I was wondering this too - we need to use Cocoon's own
capabilities to solve these very real issues. There was a
thread on this, but it went quiet. The discussion came around
to "why is Cocoon not generating the content on the
xml.apache.org/cocoon/ site".
 [Vote] Improving Cocoon Site
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100765145112325&w=2

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[David Crossley <cr...@indexgeo.com.au>]

John Morrison wrote:
> <snip/>
> >  Ugo Cei wrote:
> > > In other words, what I am proposing is that we stop worrying about being
> > > bacward compatible in order to accomodate old, buggy and non-compliant
> > > user agents, but instead start to be FORWARD compatible in order to
> > > accomodate FUTURE standard-compliant user agents.
> > >
> > > Let me know what you think about it and sorry for being slightly OT.
> 
> If we are using a live Cocoon then we can select different views
> based on the browser no?
> J.

I was wondering this too - we need to use Cocoon's own
capabilities to solve these very real issues. There was a
thread on this, but it went quiet. The discussion came around
to "why is Cocoon not generating the content on the
xml.apache.org/cocoon/ site".
 [Vote] Improving Cocoon Site
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100765145112325&w=2

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

RE: [OT] Design Rant

[John Morrison <jo...@ntlworld.com>]

<snip/>

> >
> > In other words, what I am proposing is that we stop worrying about being
> > bacward compatible in order to accomodate old, buggy and non-compliant
> > user agents, but instead start to be FORWARD compatible in order to
> > accomodate FUTURE standard-compliant user agents.
> >
> > Let me know what you think about it and sorry for being slightly OT.
>

If we are using a live Cocoon then we can select different views based on
the browser no?

J.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Stefano Mazzocchi <st...@apache.org>]

giacomo wrote:

> > > Using a CSS-based layout also means that people using 4th generation
> > > browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> > > or they will see utter garbage. Hiding the CSS from them means that they
> > > won't be able to appreciate the layout, but will nonetheless be able to
> > > read the full *content*, just not very well styled. But come on, this is
> > > a site devoted to *developers* developing for the Web. Can you imagine a
> > > web developer today using ONLY NS4 or IE4?
> 
> I know that not only developers view the apache sites. 

Correct. In fact, the apache sites should target users (I mean people
that *use* our technology to implement something), developers (those
that actually *develop* our software) and lurkers (those that don't fit
in the other categories: i.e. managers, journalists, politicians, your
mom and what not)

> I've been told
> that system administrators go here as well because the developers in
> their company like to use open source in their own software and thus the
> administrators want to know more about what they will face to
> administer.

Right, but as long as Lynx works well on our pages (and it will work
even better if we use CSS instead of HTML positional hacks)
 
> I know of manager visiting the sites to verify we told them the truth
> about open source, licensing, cool projects when we do evangelize OS
> products to them.
> 
> Those people are not on the edge of the technology (read use
> IE6/NS6.2/Mozilla browsers). They have corporate PCs with the software
> someone else has installed there and they usually are not able to change
> that.

CSS2 works decently well (besides a few bugs and missing
functionalities) on IE 5.0+ and on Netscape 6.0+

The only client that is not CSS-capable is NS4.

> I don't want to say we shouldn't go the CSS way, but we might not be
> able in all cases to show our cool sites (in terms of technology used)
> to the ones having something to say in companies where others here like
> to bring in OS software.

Absolutely.

> I know my own customers which are still using IE4 and NS4 (both have
> very diffrent implementation of CSS features)

Here is what I propose: since Sam volunteered to digest and process the
logs, why don't we come out with the percentage of people that have
non-compliant CSS2 browsers and decide with the numbers on the table?

I'd also love to see the trend, so I'd process each month separately for
the last 6 months and show a table with the results.

Sam, can we count on you for this? it would be very useful to avoid some
heat here.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Stefano Mazzocchi <st...@apache.org>]

giacomo wrote:

> > > Using a CSS-based layout also means that people using 4th generation
> > > browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> > > or they will see utter garbage. Hiding the CSS from them means that they
> > > won't be able to appreciate the layout, but will nonetheless be able to
> > > read the full *content*, just not very well styled. But come on, this is
> > > a site devoted to *developers* developing for the Web. Can you imagine a
> > > web developer today using ONLY NS4 or IE4?
> 
> I know that not only developers view the apache sites. 

Correct. In fact, the apache sites should target users (I mean people
that *use* our technology to implement something), developers (those
that actually *develop* our software) and lurkers (those that don't fit
in the other categories: i.e. managers, journalists, politicians, your
mom and what not)

> I've been told
> that system administrators go here as well because the developers in
> their company like to use open source in their own software and thus the
> administrators want to know more about what they will face to
> administer.

Right, but as long as Lynx works well on our pages (and it will work
even better if we use CSS instead of HTML positional hacks)
 
> I know of manager visiting the sites to verify we told them the truth
> about open source, licensing, cool projects when we do evangelize OS
> products to them.
> 
> Those people are not on the edge of the technology (read use
> IE6/NS6.2/Mozilla browsers). They have corporate PCs with the software
> someone else has installed there and they usually are not able to change
> that.

CSS2 works decently well (besides a few bugs and missing
functionalities) on IE 5.0+ and on Netscape 6.0+

The only client that is not CSS-capable is NS4.

> I don't want to say we shouldn't go the CSS way, but we might not be
> able in all cases to show our cool sites (in terms of technology used)
> to the ones having something to say in companies where others here like
> to bring in OS software.

Absolutely.

> I know my own customers which are still using IE4 and NS4 (both have
> very diffrent implementation of CSS features)

Here is what I propose: since Sam volunteered to digest and process the
logs, why don't we come out with the percentage of people that have
non-compliant CSS2 browsers and decide with the numbers on the table?

I'd also love to see the trend, so I'd process each month separately for
the last 6 months and show a table with the results.

Sam, can we count on you for this? it would be very useful to avoid some
heat here.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[giacomo <gi...@apache.org>]

On Wed, 19 Dec 2001, Stefano Mazzocchi wrote:

> Copied to general@ since this is a general discussion.
>
> Ugo Cei wrote:
> >
> > giacomo wrote:
> >
> > > I know :) but many sites only use *one* table to achieve the above which
> > > (at least for older browsers) result in a need to have the hole page
> > > downloaded prior to have it displayed in the browser. This above layout
> > > can display the header as soon as it is available in the browser. This
> > > way you don't have to wait in front of a blank screen too long.
> >
> > Many (well not that many, but they are starting to appear, see
> > http://www.thenoodleincident.com/tutorials/design_rant/ for example, or
> > my own http://cupva.cbim.it [C2 based]) sites use NO tables to achieve
> > layout, but instead rely completely on *standard* CSS positioning
> > properties to achieve layout.
> >
> > Let's face it: HTML <table>'s were never designed for laying out pages,
> > but for laying out tabular data. Unfortunately, since the support for
> > CSS was until recently very poor both in the browsers and in the design
> > tools, 99.9% of current web pages use tables for layout. This is IMHO an
> > ugly hack and we, as a community that strives to adhere to open
> > standards and to the concept of separation of style from content, should
> > avoid it like the plague. BTW, CSS-1 was published in 1996, so it's been
> > out for more than FIVE years, it's time that people start using it for
> > what it was meant for.
> >
> > Using a CSS-based layout also means that people using 4th generation
> > browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> > or they will see utter garbage. Hiding the CSS from them means that they
> > won't be able to appreciate the layout, but will nonetheless be able to
> > read the full *content*, just not very well styled. But come on, this is
> > a site devoted to *developers* developing for the Web. Can you imagine a
> > web developer today using ONLY NS4 or IE4?

I know that not only developers view the apache sites. I've been told
that system administrators go here as well because the developers in
their company like to use open source in their own software and thus the
administrators want to know more about what they will face to
administer.

I know of manager visiting the sites to verify we told them the truth
about open source, licensing, cool projects when we do evangelize OS
products to them.

Those people are not on the edge of the technology (read use
IE6/NS6.2/Mozilla browsers). They have corporate PCs with the software
someone else has installed there and they usually are not able to change
that.

I don't want to say we shouldn't go the CSS way, but we might not be
able in all cases to show our cool sites (in terms of technology used)
to the ones having something to say in companies where others here like
to bring in OS software.

I know my own customers which are still using IE4 and NS4 (both have
very diffrent implementation of CSS features)

Giacomo

> >
> > Incidentally, adopting a pure-CSS based solution for both layout AND
> > styling means that people using:
> >
> > - text browsers
> > - screen readers for the sight impaired
> > - mobile devices
> > - anything you cannot conceive now but that will be make web
> >    access available from your washing machine or whatever :)
> >
> > will be able to access the site contents without their "screen" or
> > reader being cluttered with spurious markup that is not in any way
> > related to the content they need.
> >
> > Before you start mentioning Cocoon's ability to select a different
> > stylesheet based on the User-Agent request parameter, keep in mind that:
> >
> > - we are talking about pregenerating a static version of the site
> >    for performance reasons
> > - as I wrote above, you cannot foresee what user agents will browse your
> >    site in the near future.
> >
> > In other words, what I am proposing is that we stop worrying about being
> > bacward compatible in order to accomodate old, buggy and non-compliant
> > user agents, but instead start to be FORWARD compatible in order to
> > accomodate FUTURE standard-compliant user agents.
> >
> > Let me know what you think about it and sorry for being slightly OT.
>
> It's a strong position but, hey, I find resonating with what you're
> saying :)
>
> We have the *luxury* to know what our user base is and estimate their
> needs very precisely.
>
> Moreover, this is a site dedicated to new technologies for the web and a
> site dedicated to evangelize open standard compliance thru reference
> implementations and cooperation.
>
> If we page a page on the 'about' section that talks about our reasons, I
> think people might even appreciate our effort to both evangelize the
> technology and 'put in practice' what we say.
>
> What do others think? (we must have a wide agreement to go forward on
> this)



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[giacomo <gi...@apache.org>]

On Wed, 19 Dec 2001, Stefano Mazzocchi wrote:

> Copied to general@ since this is a general discussion.
>
> Ugo Cei wrote:
> >
> > giacomo wrote:
> >
> > > I know :) but many sites only use *one* table to achieve the above which
> > > (at least for older browsers) result in a need to have the hole page
> > > downloaded prior to have it displayed in the browser. This above layout
> > > can display the header as soon as it is available in the browser. This
> > > way you don't have to wait in front of a blank screen too long.
> >
> > Many (well not that many, but they are starting to appear, see
> > http://www.thenoodleincident.com/tutorials/design_rant/ for example, or
> > my own http://cupva.cbim.it [C2 based]) sites use NO tables to achieve
> > layout, but instead rely completely on *standard* CSS positioning
> > properties to achieve layout.
> >
> > Let's face it: HTML <table>'s were never designed for laying out pages,
> > but for laying out tabular data. Unfortunately, since the support for
> > CSS was until recently very poor both in the browsers and in the design
> > tools, 99.9% of current web pages use tables for layout. This is IMHO an
> > ugly hack and we, as a community that strives to adhere to open
> > standards and to the concept of separation of style from content, should
> > avoid it like the plague. BTW, CSS-1 was published in 1996, so it's been
> > out for more than FIVE years, it's time that people start using it for
> > what it was meant for.
> >
> > Using a CSS-based layout also means that people using 4th generation
> > browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> > or they will see utter garbage. Hiding the CSS from them means that they
> > won't be able to appreciate the layout, but will nonetheless be able to
> > read the full *content*, just not very well styled. But come on, this is
> > a site devoted to *developers* developing for the Web. Can you imagine a
> > web developer today using ONLY NS4 or IE4?

I know that not only developers view the apache sites. I've been told
that system administrators go here as well because the developers in
their company like to use open source in their own software and thus the
administrators want to know more about what they will face to
administer.

I know of manager visiting the sites to verify we told them the truth
about open source, licensing, cool projects when we do evangelize OS
products to them.

Those people are not on the edge of the technology (read use
IE6/NS6.2/Mozilla browsers). They have corporate PCs with the software
someone else has installed there and they usually are not able to change
that.

I don't want to say we shouldn't go the CSS way, but we might not be
able in all cases to show our cool sites (in terms of technology used)
to the ones having something to say in companies where others here like
to bring in OS software.

I know my own customers which are still using IE4 and NS4 (both have
very diffrent implementation of CSS features)

Giacomo

> >
> > Incidentally, adopting a pure-CSS based solution for both layout AND
> > styling means that people using:
> >
> > - text browsers
> > - screen readers for the sight impaired
> > - mobile devices
> > - anything you cannot conceive now but that will be make web
> >    access available from your washing machine or whatever :)
> >
> > will be able to access the site contents without their "screen" or
> > reader being cluttered with spurious markup that is not in any way
> > related to the content they need.
> >
> > Before you start mentioning Cocoon's ability to select a different
> > stylesheet based on the User-Agent request parameter, keep in mind that:
> >
> > - we are talking about pregenerating a static version of the site
> >    for performance reasons
> > - as I wrote above, you cannot foresee what user agents will browse your
> >    site in the near future.
> >
> > In other words, what I am proposing is that we stop worrying about being
> > bacward compatible in order to accomodate old, buggy and non-compliant
> > user agents, but instead start to be FORWARD compatible in order to
> > accomodate FUTURE standard-compliant user agents.
> >
> > Let me know what you think about it and sorry for being slightly OT.
>
> It's a strong position but, hey, I find resonating with what you're
> saying :)
>
> We have the *luxury* to know what our user base is and estimate their
> needs very precisely.
>
> Moreover, this is a site dedicated to new technologies for the web and a
> site dedicated to evangelize open standard compliance thru reference
> implementations and cooperation.
>
> If we page a page on the 'about' section that talks about our reasons, I
> think people might even appreciate our effort to both evangelize the
> technology and 'put in practice' what we say.
>
> What do others think? (we must have a wide agreement to go forward on
> this)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [OT] Design Rant

[Stefano Mazzocchi <st...@apache.org>]

Copied to general@ since this is a general discussion.

Ugo Cei wrote:
> 
> giacomo wrote:
> 
> > I know :) but many sites only use *one* table to achieve the above which
> > (at least for older browsers) result in a need to have the hole page
> > downloaded prior to have it displayed in the browser. This above layout
> > can display the header as soon as it is available in the browser. This
> > way you don't have to wait in front of a blank screen too long.
> 
> Many (well not that many, but they are starting to appear, see
> http://www.thenoodleincident.com/tutorials/design_rant/ for example, or
> my own http://cupva.cbim.it [C2 based]) sites use NO tables to achieve
> layout, but instead rely completely on *standard* CSS positioning
> properties to achieve layout.
> 
> Let's face it: HTML <table>'s were never designed for laying out pages,
> but for laying out tabular data. Unfortunately, since the support for
> CSS was until recently very poor both in the browsers and in the design
> tools, 99.9% of current web pages use tables for layout. This is IMHO an
> ugly hack and we, as a community that strives to adhere to open
> standards and to the concept of separation of style from content, should
> avoid it like the plague. BTW, CSS-1 was published in 1996, so it's been
> out for more than FIVE years, it's time that people start using it for
> what it was meant for.
> 
> Using a CSS-based layout also means that people using 4th generation
> browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> or they will see utter garbage. Hiding the CSS from them means that they
> won't be able to appreciate the layout, but will nonetheless be able to
> read the full *content*, just not very well styled. But come on, this is
> a site devoted to *developers* developing for the Web. Can you imagine a
> web developer today using ONLY NS4 or IE4?
> 
> Incidentally, adopting a pure-CSS based solution for both layout AND
> styling means that people using:
> 
> - text browsers
> - screen readers for the sight impaired
> - mobile devices
> - anything you cannot conceive now but that will be make web
>    access available from your washing machine or whatever :)
> 
> will be able to access the site contents without their "screen" or
> reader being cluttered with spurious markup that is not in any way
> related to the content they need.
> 
> Before you start mentioning Cocoon's ability to select a different
> stylesheet based on the User-Agent request parameter, keep in mind that:
> 
> - we are talking about pregenerating a static version of the site
>    for performance reasons
> - as I wrote above, you cannot foresee what user agents will browse your
>    site in the near future.
> 
> In other words, what I am proposing is that we stop worrying about being
> bacward compatible in order to accomodate old, buggy and non-compliant
> user agents, but instead start to be FORWARD compatible in order to
> accomodate FUTURE standard-compliant user agents.
> 
> Let me know what you think about it and sorry for being slightly OT.

It's a strong position but, hey, I find resonating with what you're
saying :)

We have the *luxury* to know what our user base is and estimate their
needs very precisely.

Moreover, this is a site dedicated to new technologies for the web and a
site dedicated to evangelize open standard compliance thru reference
implementations and cooperation.

If we page a page on the 'about' section that talks about our reasons, I
think people might even appreciate our effort to both evangelize the
technology and 'put in practice' what we say.

What do others think? (we must have a wide agreement to go forward on
this)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [OT] Design Rant

[Stefano Mazzocchi <st...@apache.org>]

Copied to general@ since this is a general discussion.

Ugo Cei wrote:
> 
> giacomo wrote:
> 
> > I know :) but many sites only use *one* table to achieve the above which
> > (at least for older browsers) result in a need to have the hole page
> > downloaded prior to have it displayed in the browser. This above layout
> > can display the header as soon as it is available in the browser. This
> > way you don't have to wait in front of a blank screen too long.
> 
> Many (well not that many, but they are starting to appear, see
> http://www.thenoodleincident.com/tutorials/design_rant/ for example, or
> my own http://cupva.cbim.it [C2 based]) sites use NO tables to achieve
> layout, but instead rely completely on *standard* CSS positioning
> properties to achieve layout.
> 
> Let's face it: HTML <table>'s were never designed for laying out pages,
> but for laying out tabular data. Unfortunately, since the support for
> CSS was until recently very poor both in the browsers and in the design
> tools, 99.9% of current web pages use tables for layout. This is IMHO an
> ugly hack and we, as a community that strives to adhere to open
> standards and to the concept of separation of style from content, should
> avoid it like the plague. BTW, CSS-1 was published in 1996, so it's been
> out for more than FIVE years, it's time that people start using it for
> what it was meant for.
> 
> Using a CSS-based layout also means that people using 4th generation
> browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet
> or they will see utter garbage. Hiding the CSS from them means that they
> won't be able to appreciate the layout, but will nonetheless be able to
> read the full *content*, just not very well styled. But come on, this is
> a site devoted to *developers* developing for the Web. Can you imagine a
> web developer today using ONLY NS4 or IE4?
> 
> Incidentally, adopting a pure-CSS based solution for both layout AND
> styling means that people using:
> 
> - text browsers
> - screen readers for the sight impaired
> - mobile devices
> - anything you cannot conceive now but that will be make web
>    access available from your washing machine or whatever :)
> 
> will be able to access the site contents without their "screen" or
> reader being cluttered with spurious markup that is not in any way
> related to the content they need.
> 
> Before you start mentioning Cocoon's ability to select a different
> stylesheet based on the User-Agent request parameter, keep in mind that:
> 
> - we are talking about pregenerating a static version of the site
>    for performance reasons
> - as I wrote above, you cannot foresee what user agents will browse your
>    site in the near future.
> 
> In other words, what I am proposing is that we stop worrying about being
> bacward compatible in order to accomodate old, buggy and non-compliant
> user agents, but instead start to be FORWARD compatible in order to
> accomodate FUTURE standard-compliant user agents.
> 
> Let me know what you think about it and sorry for being slightly OT.

It's a strong position but, hey, I find resonating with what you're
saying :)

We have the *luxury* to know what our user base is and estimate their
needs very precisely.

Moreover, this is a site dedicated to new technologies for the web and a
site dedicated to evangelize open standard compliance thru reference
implementations and cooperation.

If we page a page on the 'about' section that talks about our reasons, I
think people might even appreciate our effort to both evangelize the
technology and 'put in practice' what we say.

What do others think? (we must have a wide agreement to go forward on
this)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

[OT] Design Rant (was Re: Forrest (a.k.a. xml.apache.org 2.0))

[Ugo Cei <u....@cbim.it>]

giacomo wrote:

> I know :) but many sites only use *one* table to achieve the above which
> (at least for older browsers) result in a need to have the hole page
> downloaded prior to have it displayed in the browser. This above layout
> can display the header as soon as it is available in the browser. This
> way you don't have to wait in front of a blank screen too long.


Many (well not that many, but they are starting to appear, see 
http://www.thenoodleincident.com/tutorials/design_rant/ for example, or 
my own http://cupva.cbim.it [C2 based]) sites use NO tables to achieve 
layout, but instead rely completely on *standard* CSS positioning 
properties to achieve layout.

Let's face it: HTML <table>'s were never designed for laying out pages, 
but for laying out tabular data. Unfortunately, since the support for 
CSS was until recently very poor both in the browsers and in the design 
tools, 99.9% of current web pages use tables for layout. This is IMHO an 
ugly hack and we, as a community that strives to adhere to open 
standards and to the concept of separation of style from content, should 
avoid it like the plague. BTW, CSS-1 was published in 1996, so it's been 
out for more than FIVE years, it's time that people start using it for 
what it was meant for.

Using a CSS-based layout also means that people using 4th generation 
browsers (NS 4, IE 4, etc.) must be "protected" from such a stylesheet 
or they will see utter garbage. Hiding the CSS from them means that they 
won't be able to appreciate the layout, but will nonetheless be able to 
read the full *content*, just not very well styled. But come on, this is 
a site devoted to *developers* developing for the Web. Can you imagine a 
web developer today using ONLY NS4 or IE4?

Incidentally, adopting a pure-CSS based solution for both layout AND 
styling means that people using:

- text browsers
- screen readers for the sight impaired
- mobile devices
- anything you cannot conceive now but that will be make web
   access available from your washing machine or whatever :)

will be able to access the site contents without their "screen" or 
reader being cluttered with spurious markup that is not in any way 
related to the content they need.

Before you start mentioning Cocoon's ability to select a different 
stylesheet based on the User-Agent request parameter, keep in mind that:

- we are talking about pregenerating a static version of the site
   for performance reasons
- as I wrote above, you cannot foresee what user agents will browse your
   site in the near future.

In other words, what I am proposing is that we stop worrying about being 
bacward compatible in order to accomodate old, buggy and non-compliant 
user agents, but instead start to be FORWARD compatible in order to 
accomodate FUTURE standard-compliant user agents.

Let me know what you think about it and sorry for being slightly OT.

	Ugo


-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[giacomo <gi...@apache.org>]

On Wed, 19 Dec 2001, David Crossley wrote:

> Giacomo Pati wrote:
> > David Crossley wrote:
> > > Stefano Mazzocchi wrote:
> > >
> > > > 3) layout
> > > > ---------
> > > >
> > > > The layout previously proposed on this list was a solution to the speed
> > > > problem but I couldn't adapt it to the depth needs identified in the
> > > > rest of the goals.
> > > >
> > > > So, I resurrected my rusty web design skills and came up with the layout
> > > > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > > > win2k.
> > > >
> > > > Feedback, suggestions and criticisms are appreciated.
> > >
> > > This is really great that you have taken this on Stefano,
> > > many thanks. We will all help where we can.
> > >
> > > I used "View source" to look behind-the-scenes and i see
> > > that there are still tables embedded within tables embedded
> > > within other tables. I think that this will again lead to troubles
> > > on some browsers with the larger documents.
> > >
> > > I realise that there may be a need to use one table to achieve
> > > the left-hand columns. However, i would like us to minimise the
> > > need for embedded tables, especially in the main text panel.
> >
> > Minimization is the key. Mostly you can build the initial layout using
> > three tables:
> >
> > +----------------------+
> > !       HEADER         !
> > +----------------------+
> > +---+------------------+
> > ! N !                  !
> > ! A !                  !
> > ! V !                  !
> > ! - !  CONTENT  !
> > ! B !                  !
> > ! R !                  !
> > ! R !                  !
> > +---+------------------+
> > +----------------------+
> > !       FOOTER         !
> > +----------------------+
> >
> > You can divide the HEADER and FOOTER table into more columns if needed.
> > You can also divide the NAV-BAR table into more rows as needed. But then
> > the CONTENT part is still where tables will be nested.
> >
> > IMO this is the most seedy and portable way to support even older
> > browsers.
> >
> > Giacomo
>
> The CONTENT column of the main table has been the real
> worry in the past.

I know :) but many sites only use *one* table to achieve the above which
(at least for older browsers) result in a need to have the hole page
downloaded prior to have it displayed in the browser. This above layout
can display the header as soon as it is available in the browser. This
way you don't have to wait in front of a blank screen too long.

> This is where i have seen deeply embedded
> tables used. I presume that Cocoon was doing it do achieve
> the effect of fancy section headings with background colour
> and corner images. I would like us to return to simple HTML
> with <h*> headings and <blockquote> tags.

Sure, +1.

> Even the NAV-BAR column can do without embedded tables
> by using <ul> lists (see the Avalon website).

Sure, or have it use multiple rows of that NAV-BAR/CONTENT table and
have the CONTENT part span all those rows (admittedly this might be
difficult to achieve for dynamic navbars).

Giacomo

> --David
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[David Crossley <cr...@indexgeo.com.au>]

Giacomo Pati wrote:
> David Crossley wrote:
> > Stefano Mazzocchi wrote:
> >
> > > 3) layout
> > > ---------
> > >
> > > The layout previously proposed on this list was a solution to the speed
> > > problem but I couldn't adapt it to the depth needs identified in the
> > > rest of the goals.
> > >
> > > So, I resurrected my rusty web design skills and came up with the layout
> > > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > > win2k.
> > >
> > > Feedback, suggestions and criticisms are appreciated.
> >
> > This is really great that you have taken this on Stefano,
> > many thanks. We will all help where we can.
> >
> > I used "View source" to look behind-the-scenes and i see
> > that there are still tables embedded within tables embedded
> > within other tables. I think that this will again lead to troubles
> > on some browsers with the larger documents.
> >
> > I realise that there may be a need to use one table to achieve
> > the left-hand columns. However, i would like us to minimise the
> > need for embedded tables, especially in the main text panel.
> 
> Minimization is the key. Mostly you can build the initial layout using
> three tables:
> 
> +----------------------+
> !       HEADER         !
> +----------------------+
> +---+------------------+
> ! N !                  !
> ! A !                  !
> ! V !                  !
> ! - !  CONTENT  !
> ! B !                  !
> ! R !                  !
> ! R !                  !
> +---+------------------+
> +----------------------+
> !       FOOTER         !
> +----------------------+
> 
> You can divide the HEADER and FOOTER table into more columns if needed.
> You can also divide the NAV-BAR table into more rows as needed. But then
> the CONTENT part is still where tables will be nested.
> 
> IMO this is the most seedy and portable way to support even older
> browsers.
> 
> Giacomo

The CONTENT column of the main table has been the real
worry in the past. This is where i have seen deeply embedded
tables used. I presume that Cocoon was doing it do achieve
the effect of fancy section headings with background colour
and corner images. I would like us to return to simple HTML
with <h*> headings and <blockquote> tags.

Even the NAV-BAR column can do without embedded tables
by using <ul> lists (see the Avalon website).
--David



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[David Crossley <cr...@indexgeo.com.au>]

Giacomo Pati wrote:
> David Crossley wrote:
> > Stefano Mazzocchi wrote:
> >
> > > 3) layout
> > > ---------
> > >
> > > The layout previously proposed on this list was a solution to the speed
> > > problem but I couldn't adapt it to the depth needs identified in the
> > > rest of the goals.
> > >
> > > So, I resurrected my rusty web design skills and came up with the layout
> > > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > > win2k.
> > >
> > > Feedback, suggestions and criticisms are appreciated.
> >
> > This is really great that you have taken this on Stefano,
> > many thanks. We will all help where we can.
> >
> > I used "View source" to look behind-the-scenes and i see
> > that there are still tables embedded within tables embedded
> > within other tables. I think that this will again lead to troubles
> > on some browsers with the larger documents.
> >
> > I realise that there may be a need to use one table to achieve
> > the left-hand columns. However, i would like us to minimise the
> > need for embedded tables, especially in the main text panel.
> 
> Minimization is the key. Mostly you can build the initial layout using
> three tables:
> 
> +----------------------+
> !       HEADER         !
> +----------------------+
> +---+------------------+
> ! N !                  !
> ! A !                  !
> ! V !                  !
> ! - !  CONTENT  !
> ! B !                  !
> ! R !                  !
> ! R !                  !
> +---+------------------+
> +----------------------+
> !       FOOTER         !
> +----------------------+
> 
> You can divide the HEADER and FOOTER table into more columns if needed.
> You can also divide the NAV-BAR table into more rows as needed. But then
> the CONTENT part is still where tables will be nested.
> 
> IMO this is the most seedy and portable way to support even older
> browsers.
> 
> Giacomo

The CONTENT column of the main table has been the real
worry in the past. This is where i have seen deeply embedded
tables used. I presume that Cocoon was doing it do achieve
the effect of fancy section headings with background colour
and corner images. I would like us to return to simple HTML
with <h*> headings and <blockquote> tags.

Even the NAV-BAR column can do without embedded tables
by using <ul> lists (see the Avalon website).
--David



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[giacomo <gi...@apache.org>]

On Wed, 19 Dec 2001, David Crossley wrote:

> Stefano Mazzocchi wrote:
>
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
>
> This is really great that you have taken this on Stefano,
> many thanks. We will all help where we can.
>
> I used "View source" to look behind-the-scenes and i see
> that there are still tables embedded within tables embedded
> within other tables. I think that this will again lead to troubles
> on some browsers with the larger documents.
>
> I realise that there may be a need to use one table to achieve
> the left-hand columns. However, i would like us to minimise the
> need for embedded tables, especially in the main text panel.

Minimization is the key. Mostly you can build the initial layout using
three tables:

+----------------------+
!       HEADER         !
+----------------------+
+---+------------------+
! N !                  !
! A !                  !
! V !                  !
! - !     CONTEXT      !
! B !                  !
! R !                  !
! R !                  !
+---+------------------+
+----------------------+
!       FOOTER         !
+----------------------+

You can divide the HEADER and FOOTER table into more columns if needed.
You can also divide the NAV-BAR table into more rows as needed. But then
the CONTENT part is still where tables will be nested.

IMO this is the most seedy and portable way to support even older
browsers.

Giacomo

>
> --David Crossley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[giacomo <gi...@apache.org>]

On Wed, 19 Dec 2001, David Crossley wrote:

> Stefano Mazzocchi wrote:
>
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
>
> This is really great that you have taken this on Stefano,
> many thanks. We will all help where we can.
>
> I used "View source" to look behind-the-scenes and i see
> that there are still tables embedded within tables embedded
> within other tables. I think that this will again lead to troubles
> on some browsers with the larger documents.
>
> I realise that there may be a need to use one table to achieve
> the left-hand columns. However, i would like us to minimise the
> need for embedded tables, especially in the main text panel.

Minimization is the key. Mostly you can build the initial layout using
three tables:

+----------------------+
!       HEADER         !
+----------------------+
+---+------------------+
! N !                  !
! A !                  !
! V !                  !
! - !     CONTEXT      !
! B !                  !
! R !                  !
! R !                  !
+---+------------------+
+----------------------+
!       FOOTER         !
+----------------------+

You can divide the HEADER and FOOTER table into more columns if needed.
You can also divide the NAV-BAR table into more rows as needed. But then
the CONTENT part is still where tables will be nested.

IMO this is the most seedy and portable way to support even older
browsers.

Giacomo

>
> --David Crossley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[David Crossley <cr...@indexgeo.com.au>]

Stefano Mazzocchi wrote:

> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.

This is really great that you have taken this on Stefano,
many thanks. We will all help where we can.

I used "View source" to look behind-the-scenes and i see
that there are still tables embedded within tables embedded
within other tables. I think that this will again lead to troubles
on some browsers with the larger documents.

I realise that there may be a need to use one table to achieve
the left-hand columns. However, i would like us to minimise the
need for embedded tables, especially in the main text panel.

--David Crossley

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Vadim Gritsenko <va...@verizon.net>]

> From: Torsten Curdt [mailto:tcurdt@dff.st]
> 
> > > What about NS4 and IE4 and earlier? Well ... read
> > > http://www.alistapart.com/stories/netscape/ then come back to talk
> > > about
> > > it (maybe off these lists if this is considered OT).
> >
> > hmmmm, what do others think on this?
> 
> I have to admit that this article is quite true.
> And we don't have a customer telling us "but it
> needs to look good on old browsers, too"
> 
> http://www.alistapart.com/stories/tohell/
> 
> Maybe we could analyse the logs and see what percentages
> we are talking about...

Looking into apache.org logs dated 30-Nov-2001:

2518571	TOTAL			100%
 639719	MSIE 5.5		25.4
 538746	MSIE 6+		21.3
 647472	MSIE 5+		25.7
  25102	MSIE 4+		0.99

 202024	Mozilla/5.0		8.02
 173854	Mozilla/4.7+	6.90
  62338	Mozilla/3.0+	2.47
  51407	Mozilla/4.5+	2.04
   7817	Mozilla/4.0+	0.31

 170092	OTHER			6.75

PS: MSIE entries includes compatibles (e.g.: "Mozilla/4.0 (compatible;
MSIE 5.0; Windows 2000) Opera 6.0  [en]"), Mozilla entries - also (e.g.:
" Mozilla/5.0 (compatible; Konqueror/2.2.1; Linux)")

Regards,
Vadim

> --
> Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Torsten Curdt <tc...@dff.st>]

> > What about NS4 and IE4 and earlier? Well ... read
> > http://www.alistapart.com/stories/netscape/ then come back to talk
> > about
> > it (maybe off these lists if this is considered OT).
>
> hmmmm, what do others think on this?

I have to admit that this article is quite true.
And we don't have a customer telling us "but it
needs to look good on old browsers, too"

http://www.alistapart.com/stories/tohell/

Maybe we could analyse the logs and see what percentages
we are talking about...
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Torsten Curdt <tc...@dff.st>]

> > What about NS4 and IE4 and earlier? Well ... read
> > http://www.alistapart.com/stories/netscape/ then come back to talk
> > about
> > it (maybe off these lists if this is considered OT).
>
> hmmmm, what do others think on this?

I have to admit that this article is quite true.
And we don't have a customer telling us "but it
needs to look good on old browsers, too"

http://www.alistapart.com/stories/tohell/

Maybe we could analyse the logs and see what percentages
we are talking about...
--
Torsten


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Ugo Cei wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the
> speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the
> layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5
> on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
> 
> Ok, hope this is considered constructive criticism ;).

Of course.

> I really think that we, as a community that thrives on open standards
> like XML, should do our best to adhere to such standards. 

Oh, absolutely.

> I've tested
> your page with the W3C validator and it reports 43 conformance errors
> if
>   validated against the HTML 4.01 Transitional DTD and too many errors
> to count if validated against the XHTML 1.0 Transitional DTD.

Well, I didn't aim to XHTML compliance, so that doesn't surprise me.

> As I said before, this is intended to be constructive criticism, so I
> rolled up my sleeves and transformed it into a valid XHTML 1.0
> Transitional document. I even added the nice W3C validation logo ;).

Thanks for doing this.

> I've tested it on Mozilla 0.9.6 and Opera 6.0 beta on Linux. Mozilla
> is
> fine and Opera shows a little glitch that I think could be easily
> fixed,
> I just have no time at this momento to look after it. Sorry but I
> couldn't test it under IE 5/6 at the moment.
>
> What about NS4 and IE4 and earlier? Well ... read
> http://www.alistapart.com/stories/netscape/ then come back to talk
> about
> it (maybe off these lists if this is considered OT).

hmmmm, what do others think on this?
 
> Speaking of standards conformance, besides validation, I'd like to
> rewrite this page to use a more structural markup, take all
> stylistical
> attributes (colors, sizes, margins, etc.) to CSS, and refrain from
> using
> tables and spacer gifs for layout. More on this in the coming days, if
> I
> can find an hour or two to work on it.

As long as you achieve the same visual content and you don't sacrifice
portability, I'll be very happy to include your work and give proper
credits (of course) :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Ugo Cei wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the
> speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the
> layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5
> on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
> 
> Ok, hope this is considered constructive criticism ;).

Of course.

> I really think that we, as a community that thrives on open standards
> like XML, should do our best to adhere to such standards. 

Oh, absolutely.

> I've tested
> your page with the W3C validator and it reports 43 conformance errors
> if
>   validated against the HTML 4.01 Transitional DTD and too many errors
> to count if validated against the XHTML 1.0 Transitional DTD.

Well, I didn't aim to XHTML compliance, so that doesn't surprise me.

> As I said before, this is intended to be constructive criticism, so I
> rolled up my sleeves and transformed it into a valid XHTML 1.0
> Transitional document. I even added the nice W3C validation logo ;).

Thanks for doing this.

> I've tested it on Mozilla 0.9.6 and Opera 6.0 beta on Linux. Mozilla
> is
> fine and Opera shows a little glitch that I think could be easily
> fixed,
> I just have no time at this momento to look after it. Sorry but I
> couldn't test it under IE 5/6 at the moment.
>
> What about NS4 and IE4 and earlier? Well ... read
> http://www.alistapart.com/stories/netscape/ then come back to talk
> about
> it (maybe off these lists if this is considered OT).

hmmmm, what do others think on this?
 
> Speaking of standards conformance, besides validation, I'd like to
> rewrite this page to use a more structural markup, take all
> stylistical
> attributes (colors, sizes, margins, etc.) to CSS, and refrain from
> using
> tables and spacer gifs for layout. More on this in the coming days, if
> I
> can find an hour or two to work on it.

As long as you achieve the same visual content and you don't sacrifice
portability, I'll be very happy to include your work and give proper
credits (of course) :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Robert Koberg <ro...@koberg.com>]

I was just thinking about this...

What do you think of:
-------------------------------------------
<!-- the pre class is set to a monospaced font and changes borders to make
it look different from a form input-->

<textarea rows="10" cols="80" class="pre">

myCode() {
   jhjhjhjk
   ikljkjklj
      jkhjkhjkh
      kjlhkjhjkhnkj
}

</textarea>
-------------------------------------------
This has the benefit/problem of having a (not necessarily) fixed height so
pages could be shorter.

best,
-Rob

----- Original Message -----
From: "Matt Sergeant" <ma...@sergeant.org>

> On Mon, 24 Dec 2001, John Morrison wrote:
>
> > They _were_ in the HTML spec, but have been deprecated in 4.0:
> >
> > "The deprecated WIDTH attribute of PRE tells the browser the expected
line
> > length of the preformatted block so that a suitable font size or margin
can
> > be used. Browsers ignore this attribute in practice."
>
> Hmm, interesting... Is it replaced by some CSS attribute you could use
> instead?



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[John Morrison <jo...@ntlworld.com>]

> -----Original Message-----
> From: Matt Sergeant [mailto:matt@sergeant.org]
> Sent: Monday, 24 December 2001 2:56 pm
> To: cocoon-dev@xml.apache.org
> Subject: RE: Forrest (a.k.a. xml.apache.org 2.0)
> 
> 
> On Mon, 24 Dec 2001, John Morrison wrote:
> 
> > They _were_ in the HTML spec, but have been deprecated in 4.0:
> >
> > "The deprecated WIDTH attribute of PRE tells the browser the 
> expected line
> > length of the preformatted block so that a suitable font size 
> or margin can
> > be used. Browsers ignore this attribute in practice."
> 
> Hmm, interesting... Is it replaced by some CSS attribute you could use
> instead?

Not that I'm aware of.  I'll have a longer look in the New Year.

Happy Christmas Everyone.

J.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Matt Sergeant <ma...@sergeant.org>]

On Mon, 24 Dec 2001, John Morrison wrote:

> They _were_ in the HTML spec, but have been deprecated in 4.0:
>
> "The deprecated WIDTH attribute of PRE tells the browser the expected line
> length of the preformatted block so that a suitable font size or margin can
> be used. Browsers ignore this attribute in practice."

Hmm, interesting... Is it replaced by some CSS attribute you could use
instead?

-- 
<!-- Matt -->
<:->Get a smart net</:->


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[John Morrison <jo...@ntlworld.com>]

They _were_ in the HTML spec, but have been deprecated in 4.0:

"The deprecated WIDTH attribute of PRE tells the browser the expected line
length of the preformatted block so that a suitable font size or margin can
be used. Browsers ignore this attribute in practice."

Nice though - would have been useful.

J.

> -----Original Message-----
> From: Matt Sergeant [mailto:matt@sergeant.org]
> Sent: Monday, 24 December 2001 2:02 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: Forrest (a.k.a. xml.apache.org 2.0)
>
>
> On Sun, 23 Dec 2001, Stefano Mazzocchi wrote:
>
> > > Is <pre> the only possibility for displaying source code?
> >
> > Well, we need a monospaced font or you can say goodbye to your nice
> > indentation. And tell me how we can have xml and java examples without
> > respected indentation.
> >
> > If you have suggestions, I'm wide open.
>
> FWIW, I use <pre width="80" cols="80"> on some sites. Seems to take care
> of wrapping quite neatly, although I don't think those attributes are in
> the HTML spec.
>
> --
> <!-- Matt -->
> <:->Get a smart net</:->
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Matt Sergeant <ma...@sergeant.org>]

On Sun, 23 Dec 2001, Stefano Mazzocchi wrote:

> > Is <pre> the only possibility for displaying source code?
>
> Well, we need a monospaced font or you can say goodbye to your nice
> indentation. And tell me how we can have xml and java examples without
> respected indentation.
>
> If you have suggestions, I'm wide open.

FWIW, I use <pre width="80" cols="80"> on some sites. Seems to take care
of wrapping quite neatly, although I don't think those attributes are in
the HTML spec.

-- 
<!-- Matt -->
<:->Get a smart net</:->


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Ugo Cei wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > Jeremy Quinn wrote:
> 
> >>Consider limiting the width of the body text, for ergonomic reasons.
> >>
> >
> > Can't do that since we'll have <pre> blocks with source code that will
> > dictate how big the width is. (I'm working with 80 columns <pre> blocks
> > just for testing but that's a problem with source-including HTML docs)
> 
> The current Cocoon site has many pages that cannot be printed (at least
> with Mozilla) because the width of the <pre> blocks is so large that the
> width of many pages is bigger than a printed page, thus the righmost
> characters of all lines are truncated.

Right. We'll work on a print-friendly solution with PDF... but still the
best way to do this is to accept guidelines that no more than 80 columns
should be used for source code chunks into docs or the system is not
guaranteed to work as expected.

> Is <pre> the only possibility for displaying source code?

Well, we need a monospaced font or you can say goodbye to your nice
indentation. And tell me how we can have xml and java examples without
respected indentation.

If you have suggestions, I'm wide open.

> By the way, Courier on the screen sucks badly :).

Again, I'm wide open to suggestions.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Ugo Cei <u....@cbim.it>]

Stefano Mazzocchi wrote:

> Jeremy Quinn wrote:


>>Consider limiting the width of the body text, for ergonomic reasons.
>>
> 
> Can't do that since we'll have <pre> blocks with source code that will
> dictate how big the width is. (I'm working with 80 columns <pre> blocks
> just for testing but that's a problem with source-including HTML docs)

The current Cocoon site has many pages that cannot be printed (at least 
with Mozilla) because the width of the <pre> blocks is so large that the 
width of many pages is bigger than a printed page, thus the righmost 
characters of all lines are truncated.

Is <pre> the only possibility for displaying source code? By the way, 
Courier on the screen sucks badly :).

	Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Jeremy Quinn wrote:
> 
> At 2:24 pm -0500 18/12/01, Vadim Gritsenko wrote:
> >Changes:
> >
> > - Now all style information is gathered in one standalone CSS file.
> > - Three tables left.
> 
> Sorry I am a bit behind with the list .....
> 
> May I suggest:
> 
> Consider using the unit pixel (px) instead of the unit point (pt) for font
> sizes, as this (I believe) ensures the closest possible similarity
> x-platform regarding font sizes.
> 
> Consider providing styles for the body text, Times is unsuitable IMHO.

Yes, this has been considered.

> Consider limiting the width of the body text, for ergonomic reasons.

Can't do that since we'll have <pre> blocks with source code that will
dictate how big the width is. (I'm working with 80 columns <pre> blocks
just for testing but that's a problem with source-including HTML docs)
 
> Consider removing underlines from links in the sidebar and path (like you
> have in the tabs), IMHO they are obviously links, and are easier to read
> without the decoration, leave them on in the body text.

-1, underline is now considered part of visual semantics to indicate
hyperlinking and making a cursor change (or a hover effect) doesn't give
a global 'at-once' perception of the hyperlink space of the page.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Peter Royal wrote:
> 
> On Friday 21 December 2001 09:09 am, you wrote:
> > > Times is the default style. But yes, verdana is the best font for screen
> > > use.  Serif  fonts(fonts with tails,  like Times New Roman) are not built
> > > for the screen.
> >
> > Agreed. Tahoma (the windows default font for everything in the windows
> > like menubars and others) is another choice, but not sure about
> > availability on non-win32 systems.
> 
> Tahoma is not free, but Verdana is:
> http://www.microsoft.com/typography/fontpack/default.htm

Ok, that pretty much rules it out by itself.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Peter Royal <pr...@managingpartners.com>]

On Friday 21 December 2001 09:09 am, you wrote:
> > Times is the default style. But yes, verdana is the best font for screen
> > use.  Serif  fonts(fonts with tails,  like Times New Roman) are not built
> > for the screen.
>
> Agreed. Tahoma (the windows default font for everything in the windows
> like menubars and others) is another choice, but not sure about
> availability on non-win32 systems.

Tahoma is not free, but Verdana is:
http://www.microsoft.com/typography/fontpack/default.htm

-pete

-- 
peter royal -> proyal@managingpartners.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Robert Koberg <ro...@koberg.com>]

> > Points of contention
> > There are approximately 72 points per inch. To match this, Mac OS offers
a
> > default resolution of 72 pixels per inch, mapping pixels to points. Of
> > course, once the Mac user changes her screen resolution, all bets are
off.
>
> Yes, and IE browser (5+) for Mac's default setting is 96 pixels per inch
> now.
>


Brilliant example!  The workaround for this in the past was to write a
little javascript browser sniffer to detect the platform.  After MacIE5 if
you still want to use pixels you have to rewrite the javascript to detect
not only platform but browser, so you can still give Nav the version based
on 72dpi.  More proof to use em, in my opinion.

best,
-Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Diana Shannon <te...@mac.com>]

>>>> 
>>>> Consider using the unit pixel (px) instead of the unit point (pt) for
> font
>>>> sizes, as this (I believe) ensures the closest possible similarity
>>>> x-platform regarding font sizes.
>>> 
>>> this is extremely wrong. An inch on a mac screen contains far less
> pixels
>>> (72?) than a windows pc screen (96?).
>> 
>> Where did you read this from? Mac and Windows have different default
>> gamma correction settings, but dpi is a property of screens, not a
>> software property (and both OS assume 72 dpi)
> 
> from my past with cdrom apps, but also, I just snipped the following from
> the article (http://www.alistapart.com/stories/fear4/index.html) Diana
> Shannon suggested in this thread:
> Points of contention
> There are approximately 72 points per inch. To match this, Mac OS offers a
> default resolution of 72 pixels per inch, mapping pixels to points. Of
> course, once the Mac user changes her screen resolution, all bets are off.

Yes, and IE browser (5+) for Mac's default setting is 96 pixels per inch
now.

Diana


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Robert Koberg <ro...@koberg.com>]

>----- Original Message -----
>From: "Stefano Mazzocchi" <st...@apache.org>


> Robert Koberg wrote:
> >
> > >
> > > Consider using the unit pixel (px) instead of the unit point (pt) for
font
> > > sizes, as this (I believe) ensures the closest possible similarity
> > > x-platform regarding font sizes.
> >
> > this is extremely wrong. An inch on a mac screen contains far less
pixels
> > (72?) than a windows pc screen (96?).
>
> Where did you read this from? Mac and Windows have different default
> gamma correction settings, but dpi is a property of screens, not a
> software property (and both OS assume 72 dpi)

from my past with cdrom apps, but also, I just snipped the following from
the article (http://www.alistapart.com/stories/fear4/index.html) Diana
Shannon suggested in this thread:
Points of contention
There are approximately 72 points per inch. To match this, Mac OS offers a
default resolution of 72 pixels per inch, mapping pixels to points. Of
course, once the Mac user changes her screen resolution, all bets are off.
In Windows and other PC operating systems, there are 96 pixels inch - until
the PC user changes her screen resolution, and then all bets are off.


<snip/>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Robert Koberg wrote:
> 
> >
> > Consider using the unit pixel (px) instead of the unit point (pt) for font
> > sizes, as this (I believe) ensures the closest possible similarity
> > x-platform regarding font sizes.
> 
> this is extremely wrong. An inch on a mac screen contains far less pixels
> (72?) than a windows pc screen (96?). 

Where did you read this from? Mac and Windows have different default
gamma correction settings, but dpi is a property of screens, not a
software property (and both OS assume 72 dpi)

> > Consider providing styles for the body text, Times is unsuitable IMHO.
> 
> Times is the default style. But yes, verdana is the best font for screen
> use.  Serif  fonts(fonts with tails,  like Times New Roman) are not built
> for the screen.

Agreed. Tahoma (the windows default font for everything in the windows
like menubars and others) is another choice, but not sure about
availability on non-win32 systems.
 
> >
> > Consider limiting the width of the body text, for ergonomic reasons.
> >
> 
> the user can do this by themselves by resizing the browser. What if they
> want narrower columns than you allow?

I agree.
 
> > Consider removing underlines from links in the sidebar and path (like you
> > have in the tabs), IMHO they are obviously links, and are easier to read
> > without the decoration, leave them on in the body text.
> 
> The only thing I have to say on this is that most people know when you see a
> colored, underlined word or phrase that if clicked will take them somewhere
> else. But I would be open to usability studies :)

Exactly, let's keep the visual semantics coherent.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Diana Shannon <te...@mac.com>]

>> 
>>> Well, the following article makes a reasonable argument for pixels. You
> may
>>> want to check out:
>>> http://www.alistapart.com/stories/fear4/index.html

>> The situation with font sizes is extremely pickled!
>> Yes Mac is based on 72 dpi and Windows defaults to 96 dpi, but it is more
>> complicated than this ..... for instance new versions of IE for Mac
>> "emulate" 96dpi, to try and limit the difference.
>> 
> 
> Yes, and so does nav6.  But this is irrelevant to the fact that if you use
> pixels YOU (not the user) are determining the best text size for the user.
> Sometimes it is too big, more often too small. With pixels the user cannot
> adjust your page so they can read it comfortably.

...

> It is amazing to me that there is an argument.

We seem to be splitting hairs over the term "relative", whether to use the
em's "relative to the parent font element (or user settings)" approach or to
use the pixel's "relative to screen setting" approach. I think the fact the
argument remains is due to the fact that some of us have clients who insist
on rather tight __cross-platform consistency__ of layouts. Right or wrong
(in terms of accessibility) pixels give you the most control. (And please
note that a number of browsers allow the user to override even pixels
settings.) Pixels are still appropriate, for instance, if you have to match
text to a specific image size, etc.

I do agree 100% with Rob that we should choose readability/accessibility
over cross-platform consistency. For that, ems are the better choice,
assuming you don't specify an absolute value for the parent font element in
the css, leaving it up to the values specified in the user's browser.

Diana 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Robert Koberg <ro...@koberg.com>]

>
> >Well, the following article makes a reasonable argument for pixels. You
may
> >want to check out:
> >http://www.alistapart.com/stories/fear4/index.html
>
>
> So does this (with screenshots).
>
> <http://developer.apple.com/internet/fonts/fonts_sizing.html>
> and
> <http://developer.apple.com/internet/fonts/fonts_gallery.html>
>
> The situation with font sizes is extremely pickled!
> Yes Mac is based on 72 dpi and Windows defaults to 96 dpi, but it is more
> complicated than this ..... for instance new versions of IE for Mac
> "emulate" 96dpi, to try and limit the difference.
>

Yes, and so does nav6.  But this is irrelevant to the fact that if you use
pixels YOU (not the user) are determining the best text size for the user.
Sometimes it is too big, more often too small. With pixels the user cannot
adjust your page so they can read it comfortably. This immediately makes
your site fail usability tests (unless your target groups only contains
people with good eyesight).

Maybe as ?designers? you should design for the medium. Just because some
person took the time to put some ideas on a web page doesn't make it
right... think different...

It is amazing to me that there is an argument. If both (nav & ie) late
version browsers default to 96dpi then em based fonts will look the same
cross platform and it won't eliminate browsers based on 72dpi.. Of course
the tricky thing about em's is using the 'cascading' feature. But once you
understand that you can make your page more _elegant_. Consider this example
of cascading em based fonts but still retaining the structure of the xml:

<html>
<head>
 <title>Untitled</title>
<style>
body {font-family:verdana,helvetica,sans-serif;}
span.article {font-size: 1em}
span.section { font-size: .9em}
div.title {font-size: 1.2em; font-weight:bold}
div.para {font-size: .9em}
</style>

</head>

<body>


<span class="article">
    <div class="title">My main title</div>
    <div class="para">My main para</div>
    <span class="section">
        <div class="title">My sub title</div>
        <div class="para">My sub para</div>
        <span class="section">
            <div class="title">My subsub title</div>
            <div class="para">My subsub para</div>
        </span>
    </span>
</span>

</body>
</html>
---------------------------------


best,
-Rob




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Jeremy Quinn <je...@media.demon.co.uk>]

At 9:23 am -0500 21/12/01, Diana Shannon wrote:
>>> Consider using the unit pixel (px) instead of the unit point (pt) for font
>>> sizes, as this (I believe) ensures the closest possible similarity
>>> x-platform regarding font sizes.
>>
>> this is extremely wrong. An inch on a mac screen contains far less pixels
>> (72?) than a windows pc screen (96?). The best cross-platform unit sizing
>> for good control is 'em'
>> -- so you will have wide variations between platforms if you use px.  In
>> addition your users cannot resize the text if they want to see it larger.

The relative screen real estate will be different, but the size
relationship between the parts (images, fonts, table-widths etc) will
remain the same.

>Well, the following article makes a reasonable argument for pixels. You may
>want to check out:
>http://www.alistapart.com/stories/fear4/index.html


So does this (with screenshots).

	<http://developer.apple.com/internet/fonts/fonts_sizing.html>
and
	<http://developer.apple.com/internet/fonts/fonts_gallery.html>

The situation with font sizes is extremely pickled!
Yes Mac is based on 72 dpi and Windows defaults to 96 dpi, but it is more
complicated than this ..... for instance new versions of IE for Mac
"emulate" 96dpi, to try and limit the difference.

regards Jeremy
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <ma...@mac.com>     		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Diana Shannon <te...@mac.com>]

>> Consider using the unit pixel (px) instead of the unit point (pt) for font
>> sizes, as this (I believe) ensures the closest possible similarity
>> x-platform regarding font sizes.
> 
> this is extremely wrong. An inch on a mac screen contains far less pixels
> (72?) than a windows pc screen (96?). The best cross-platform unit sizing
> for good control is 'em'
> -- so you will have wide variations between platforms if you use px.  In
> addition your users cannot resize the text if they want to see it larger.

Well, the following article makes a reasonable argument for pixels. You may
want to check out:
http://www.alistapart.com/stories/fear4/index.html

Diana


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Robert Koberg <ro...@koberg.com>]

>
> Consider using the unit pixel (px) instead of the unit point (pt) for font
> sizes, as this (I believe) ensures the closest possible similarity
> x-platform regarding font sizes.

this is extremely wrong. An inch on a mac screen contains far less pixels
(72?) than a windows pc screen (96?). The best cross-platform unit sizing
for good control is 'em'
-- so you will have wide variations between platforms if you use px.  In
addition your users cannot resize the text if they want to see it larger.

>
> Consider providing styles for the body text, Times is unsuitable IMHO.

Times is the default style. But yes, verdana is the best font for screen
use.  Serif  fonts(fonts with tails,  like Times New Roman) are not built
for the screen.

>
> Consider limiting the width of the body text, for ergonomic reasons.
>

the user can do this by themselves by resizing the browser. What if they
want narrower columns than you allow?


> Consider removing underlines from links in the sidebar and path (like you
> have in the tabs), IMHO they are obviously links, and are easier to read
> without the decoration, leave them on in the body text.

The only thing I have to say on this is that most people know when you see a
colored, underlined word or phrase that if clicked will take them somewhere
else. But I would be open to usability studies :)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

[OT] RE: Forrest (a.k.a. xml.apache.org 2.0)

[Jeremy Quinn <je...@media.demon.co.uk>]

At 8:38 am -0500 21/12/01, Vadim Gritsenko wrote:
>I guess it is because of "Forrest Gump".
>http://movies.yahoo.com/shop?d=hv&cf=info&id=1800217371&intl=us
>
>PS Btw, interesting movie...

Ah, a real name, not a typo, did not think of that, guess I need to get out
to the cinema more often ;)

Jeremy
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <ma...@mac.com>     		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

[OT] RE: Forrest (a.k.a. xml.apache.org 2.0)

[Vadim Gritsenko <va...@verizon.net>]

I guess it is because of "Forrest Gump".
http://movies.yahoo.com/shop?d=hv&cf=info&id=1800217371&intl=us

PS Btw, interesting movie...

Vadim

> -----Original Message-----
> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> Sent: Friday, December 21, 2001 5:45 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: Forrest (a.k.a. xml.apache.org 2.0)
> 
> 
> I forgot to say ......
> 
> Any particular reason why Forrest (sic) is misspelt?
> 
> If it is not an acronym and is meant to be an English word, maybe we
should
> call it Forest?
> 
> regards Jeremy
> --
>    ___________________________________________________________________
> 
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
> 
>    <ma...@mac.com>
<http://www.media.demon.co.uk>
>    <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Jeremy Quinn <je...@media.demon.co.uk>]

I forgot to say ......

Any particular reason why Forrest (sic) is misspelt?

If it is not an acronym and is meant to be an English word, maybe we should
call it Forest?

regards Jeremy
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <ma...@mac.com>     		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Jeremy Quinn <je...@media.demon.co.uk>]

At 2:24 pm -0500 18/12/01, Vadim Gritsenko wrote:
>Changes:
>
> - Now all style information is gathered in one standalone CSS file.
> - Three tables left.


Sorry I am a bit behind with the list .....

May I suggest:

Consider using the unit pixel (px) instead of the unit point (pt) for font
sizes, as this (I believe) ensures the closest possible similarity
x-platform regarding font sizes.

Consider providing styles for the body text, Times is unsuitable IMHO.

Consider limiting the width of the body text, for ergonomic reasons.

Consider removing underlines from links in the sidebar and path (like you
have in the tabs), IMHO they are obviously links, and are easier to read
without the decoration, leave them on in the body text.


regards Jeremy

-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <ma...@mac.com>    		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Ugo Cei <u....@cbim.it>]

Vadim Gritsenko wrote:

> Changes:
> 
>  - Now all style information is gathered in one standalone CSS file.
>  - Three tables left.
> 
> Ugo, if/when you have time - modify this version for Opera.

This is the best I could do but I'm still having problems. I think I'll 
redo the tabs using something different, since it really bothers me to 
have stupid small gifs littering the content (take a look at the thread 
I started under the "[OT] Design Rant" title for mi views on the matter).

More on this later.

	Ugo


-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Vadim Gritsenko <va...@verizon.net>]

Changes:

 - Now all style information is gathered in one standalone CSS file.
 - Three tables left.

Ugo, if/when you have time - modify this version for Opera.

Thanks,
Vadim

> From: Ugo Cei [mailto:u.cei@cbim.it]
> 
> Vadim Gritsenko wrote:
> 
> 
> > Ugo,
> > Could you test this page again on Opera?
> > It looks good on IE6 and Mozilla 0.9.6 (windows).
> 
> 
> There is a glitch in the display of the tabs in Opera 6. Will look
after
> it when I have time.
> 
> 
> > PS Did not check though these modifications for HTML/XHTML
> > conformance...
> 
> 
> There were a couple of problems, fixed in the attached version.
> 
> 
> 	Ugo
> 
> --
> Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> Phone: +39.0382.525100 - E-mail: u.cei@cbim.it

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Ugo Cei <u....@cbim.it>]

Vadim Gritsenko wrote:

 
> Ugo,
> Could you test this page again on Opera?
> It looks good on IE6 and Mozilla 0.9.6 (windows).


There is a glitch in the display of the tabs in Opera 6. Will look after 
it when I have time.

 
> PS Did not check though these modifications for HTML/XHTML
> conformance...


There were a couple of problems, fixed in the attached version.
	

	Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Berin Loritsch <bl...@apache.org>]

Vadim Gritsenko wrote:

> Ok, here is modified version:
>  - Google search works;
>  - Reduced <table>s count in two times ;)
>  - No more dot.gif!
> 
> Ugo,
> Could you test this page again on Opera?
> It looks good on IE6 and Mozilla 0.9.6 (windows).
> 
> PS Did not check though these modifications for HTML/XHTML
> conformance...


All you have to do now is separate out the CSS styles into a separate file
to take advantage of browser caching to further reduce the size of the
pages.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Forrest (a.k.a. xml.apache.org 2.0)

[Vadim Gritsenko <va...@verizon.net>]

Ok, here is modified version:
 - Google search works;
 - Reduced <table>s count in two times ;)
 - No more dot.gif!

Ugo,
Could you test this page again on Opera?
It looks good on IE6 and Mozilla 0.9.6 (windows).

PS Did not check though these modifications for HTML/XHTML
conformance...

Regards,
Vadim

> -----Original Message-----
> From: Ugo Cei [mailto:u.cei@cbim.it]
> Sent: Tuesday, December 18, 2001 4:41 AM
> To: cocoon-dev@xml.apache.org
> Cc: Apache XML
> Subject: Re: Forrest (a.k.a. xml.apache.org 2.0)
> 
> Stefano Mazzocchi wrote:
> 
> > 3) layout
> > ---------
> >
> > The layout previously proposed on this list was a solution to the
speed
> > problem but I couldn't adapt it to the depth needs identified in the
> > rest of the goals.
> >
> > So, I resurrected my rusty web design skills and came up with the
layout
> > you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5
on
> > win2k.
> >
> > Feedback, suggestions and criticisms are appreciated.
> 
> 
> Ok, hope this is considered constructive criticism ;).
> 
> I really think that we, as a community that thrives on open standards
> like XML, should do our best to adhere to such standards. I've tested
> your page with the W3C validator and it reports 43 conformance errors
if
>   validated against the HTML 4.01 Transitional DTD and too many errors
> to count if validated against the XHTML 1.0 Transitional DTD.
> 
> As I said before, this is intended to be constructive criticism, so I
> rolled up my sleeves and transformed it into a valid XHTML 1.0
> Transitional document. I even added the nice W3C validation logo ;).
> 
> I've tested it on Mozilla 0.9.6 and Opera 6.0 beta on Linux. Mozilla
is
> fine and Opera shows a little glitch that I think could be easily
fixed,
> I just have no time at this momento to look after it. Sorry but I
> couldn't test it under IE 5/6 at the moment.
> 
> What about NS4 and IE4 and earlier? Well ... read
> http://www.alistapart.com/stories/netscape/ then come back to talk
about
> it (maybe off these lists if this is considered OT).
> 
> Speaking of standards conformance, besides validation, I'd like to
> rewrite this page to use a more structural markup, take all
stylistical
> attributes (colors, sizes, margins, etc.) to CSS, and refrain from
using
> tables and spacer gifs for layout. More on this in the coming days, if
I
> can find an hour or two to work on it.
> 
> 
> 	Ugo
> 
> --
> Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> Phone: +39.0382.525100 - E-mail: u.cei@cbim.it

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Ugo Cei <u....@cbim.it>]

Stefano Mazzocchi wrote:

> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.


Ok, hope this is considered constructive criticism ;).

I really think that we, as a community that thrives on open standards 
like XML, should do our best to adhere to such standards. I've tested 
your page with the W3C validator and it reports 43 conformance errors if 
  validated against the HTML 4.01 Transitional DTD and too many errors 
to count if validated against the XHTML 1.0 Transitional DTD.

As I said before, this is intended to be constructive criticism, so I 
rolled up my sleeves and transformed it into a valid XHTML 1.0 
Transitional document. I even added the nice W3C validation logo ;).

I've tested it on Mozilla 0.9.6 and Opera 6.0 beta on Linux. Mozilla is 
fine and Opera shows a little glitch that I think could be easily fixed, 
I just have no time at this momento to look after it. Sorry but I 
couldn't test it under IE 5/6 at the moment.

What about NS4 and IE4 and earlier? Well ... read 
http://www.alistapart.com/stories/netscape/ then come back to talk about 
it (maybe off these lists if this is considered OT).

Speaking of standards conformance, besides validation, I'd like to 
rewrite this page to use a more structural markup, take all stylistical 
attributes (colors, sizes, margins, etc.) to CSS, and refrain from using 
tables and spacer gifs for layout. More on this in the coming days, if I 
can find an hour or two to work on it.


	Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

max@corrosive.co.uk wrote:
> 
> >3) Navigation: the navigation experience on current xml.apache.org is a
> >nightmare. There is no way to perceive the basic elements of spatial
> >navigation: where am I? where can I go? how do I go back? how do I go
> >there?
> 
> This navigation seems to definitely do a better job. You now have 2
> ways of structuring/navigate the info with the left and top nav.

Thank you. I still don't think it's perfect... expect an improved
version soon.

> >3) layout
> >---------
> >
> >The layout previously proposed on this list was a solution to the speed
> >problem but I couldn't adapt it to the depth needs identified in the
> >rest of the goals.
> >
> >So, I resurrected my rusty web design skills and came up with the layout
> >you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> >win2k.
> >
> >Feedback, suggestions and criticisms are appreciated.
> 
> Comments:
> 
> - while the Cocoon logo is sharp and neat, the xml.apache one seems a
> bit "washed out" with respect to the previous - can't that one be
> used?

Good point. +1

> - can the background of the main content area be of the same colour
> as for the selected tab (white in this case)?

Right, was a bug in my HTML. Already fixed.
 
> - is the main content going to be without "style"?

No, I concentrated on the navigation part, I'll come up with a complete
example in my next version of the layout.

> Stefano, as always I'm up to work these out, if you want. Just let me know.

I'll be honored if you help me out.

Expect a 1.1 version in a couple of days, let's work on that one.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[ma...@corrosive.co.uk]

>3) Navigation: the navigation experience on current xml.apache.org is a
>nightmare. There is no way to perceive the basic elements of spatial
>navigation: where am I? where can I go? how do I go back? how do I go
>there?

This navigation seems to definitely do a better job. You now have 2 
ways of structuring/navigate the info with the left and top nav.


>3) layout
>---------
>
>The layout previously proposed on this list was a solution to the speed
>problem but I couldn't adapt it to the depth needs identified in the
>rest of the goals.
>
>So, I resurrected my rusty web design skills and came up with the layout
>you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
>win2k.
>
>Feedback, suggestions and criticisms are appreciated.

Comments:

- while the Cocoon logo is sharp and neat, the xml.apache one seems a 
bit "washed out" with respect to the previous - can't that one be 
used?

- can the background of the main content area be of the same colour 
as for the selected tab (white in this case)?

- is the main content going to be without "style"?

Stefano, as always I'm up to work these out, if you want. Just let me know.


Cheers
Max
-- 

------------------------------

Max Guglielmino
Corrosive
http://www.corrosive.co.uk


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:

> GOALS
> -----
> 
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.


Not to mention that users simply go somewhere else....


> 
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.


This is pretty evident.  There is also no standard heirarchy of docs,
and some projects don't even publish the API docs!


> 
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?


The proposed navigation is pretty cool.  Well thought out.


> 
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.


Yep.  This is exacerbated by the fact that people question "Where are the
docs?"  When there were something like 20 links reduced down to 4 (each new
link is a more well thought out documentation type such as Installation,
tutorial/how to use it, developer's docs, etc.)


> 
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
> 
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.


I think this is the biggest complaint--and one why only simple to use
tools like JAXP compliant XML and XSLT processors get wide distribution.

> 
> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 


It looks great.  I like the layout even more.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[David Crossley <cr...@indexgeo.com.au>]

Stefano Mazzocchi wrote:

> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.

This is really great that you have taken this on Stefano,
many thanks. We will all help where we can.

I used "View source" to look behind-the-scenes and i see
that there are still tables embedded within tables embedded
within other tables. I think that this will again lead to troubles
on some browsers with the larger documents.

I realise that there may be a need to use one table to achieve
the left-hand columns. However, i would like us to minimise the
need for embedded tables, especially in the main text panel.

--David Crossley

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:

> GOALS
> -----
> 
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.


Not to mention that users simply go somewhere else....


> 
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.


This is pretty evident.  There is also no standard heirarchy of docs,
and some projects don't even publish the API docs!


> 
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?


The proposed navigation is pretty cool.  Well thought out.


> 
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.


Yep.  This is exacerbated by the fact that people question "Where are the
docs?"  When there were something like 20 links reduced down to 4 (each new
link is a more well thought out documentation type such as Installation,
tutorial/how to use it, developer's docs, etc.)


> 
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
> 
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.


I think this is the biggest complaint--and one why only simple to use
tools like JAXP compliant XML and XSLT processors get wide distribution.

> 
> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 


It looks great.  I like the layout even more.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

["Theodore W. Leung" <tw...@sauria.com>]

On Sun, 2001-12-16 at 13:33, Stefano Mazzocchi wrote:
> [sorry for cross-post: this is a general issue, but I'd like the cocoon
> people to know what I'm doing so that they might give me a hand :)]
> 
> I started the effort that will, hopefully, bring us a much more useful
> documentation system for xml.apache.org and, hopefully, to the entire
> ASF, even if political and ego obstacles will get in the way.
> 
> I personally don't care: this effort is mainly to create a better
> documentation infrastructure following the goals outlined below. I
> started the Cocoon project three years ago exactly for this reason and
> now that has all the features I needed, I think I can attack the problem
> from a very wide angle. 
> 
> The site building system will be targetted toward xml.apache.org, but
> I'll keep a very broad perspective, making it possible to adapt the
> system to other apache.org projects with very few changes.
> 
> BIG DISCLAIMER: however, whether this happens or not, I personally don't
> care. For sure, don't count on me wasting my time on fighting about 'my
> DTD is better than yours' or 'my system is
> faster/smaller/cleaner/easier-to-use/more-extensible than yours'.
> 
> I'll come up with a system that works and then you guys will vote on
> what to do. I consider this an exercise to present full Cocoon
> potentials (that, objectively, beat the pants out of all the other
> systems used around Apache) but nothing more than this.
> 
>                                     - o -
> 
> Ok, now that I stated this, let's get into the effort goals.
> 
> GOALS
> -----
> 
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.
> 
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.
> 
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?
> 
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.
> 
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
> 
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.
> 
> 7) Extensibility, Flexibility, Modularity: web sites, just as software,
> are living entities that adapt on their environment. The build system
> must not restrict the ability to evolutionary extend the information
> architecture.
> 
> 8) URI Solidity and Future Compatibility: URIs are contracts between the
> publisher and the user. Human users have the ability to estimate the
> long-term validity of these contracts and 'route around' eventual broken
> links, while machine users do not. The goal is to come up with a system
> that allows to generate a web site with strong URIs.
> 
> 
> Design Decisions
> ----------------
> 
> staticity: even if I think that the availability of a dynamic publishing
> system would be beneficial, considering the web site load, the load of
> the apache machines and the state of the JVM for FreeBSD and the
> political problems behind all this, it's *must* easier (at least for
> now) to have a static version of the site batch-produced and then placed
> into the web-serving space.
+1
> automaticity: the site will be automatically generated out of files
> stored into CVS. The idea is to have GUMP-like nagging features that
> send email to the various mail lists using XML validation to estimate
> the 'integrity' of the docs placed.
+1
> For this reason, in honor of Sam Ruby's great work, and for the
> resonation with 'forest', thus a huge number of trees (i.e. XML files),
> I call this effort "Forrest".
> 
> I believe that together, Forrest and Gump, will help bringing apache
> quality one step up (moreover, as in the name, forrest wraps gump and
> will publish its generated data, providing more overall coherence)
> 
>                                         - o -
> 
> separation of concerns
> ----------------------
> 
> There are three concern islands, here is a list of their duties.
> 
> subproject
> ==========
> 
> each subproject should provide:
> 3.a) a 'description' file that includes information on the codebase, its
> description, its released versions, its CVS modules, its CVS tags, its
> mail lists and its documentations (yes, a subproject might have more
> than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
> [proposed filename: /description.xml]
>  
> 3.b) a 'committers info' file that includes information on the
> committers, along with a short bio, an email address and a picture of
> them. [proposed filename: /committers.xml]
> 
> 3.c) a 'change log' file that includes information on changes and
> software relases [proposed filename: /changes.xml]
> 
> 3.d) a 'todo list' file that includes the information on things to do
> and who volunteered for doing it [proposed filename: /todo.xml]
> 
> 3.e) a 'news' file that includes events and useful information that
> should be made available to the general public.
> 
> then, for each documentation (location is get from the description
> file):
> 
> 3.f) a 'table of content' that indicates the hierarchical sequence of
> the files and where to find them into the CVS repository (for each
> documentation). This is kept as a single file to allow document writers
> to maintain 'coherence' and visualize the entire part. This is
> equivalent to the stylebook book.xml file but with full nesting
> capabilities.
> 
> 3.e) the pages that componse the documentation (their location is get
> from the ToC file)
> 
> Log scanner
> ===========
> 
> The log scanner is a set of scripts that scan the logs from the CVS, the
> mail lists and the web site to gather information on:
> 
>  1) mail list activity (subscribers and messages)
>  2) web site activity (hits and downloads)
>  3) CVS activity (general commits, commits per person)
> 
> This scanner provides this information in a simple format that can be
> easily fed into the documentation building system.
> 
> Build system
> ============
> 
> The build system will:
> 
> 1) aggregate, filter and otherwise adapt the information collected from
> the various subprojects CVS modules, from the log scanner and from the
> GUMP run into static HTML files (for the browser pages), static PDF
> files (for print-friendly versions) and JPEG images (for graphs).
> 
> 2) generate navigation information in all the pages
> 
> 3) check validation of all the required XML files and send nag messages
> to the mail lists if failure occurs.
> 
> 4) generate httpd-related corollary files (.htaccess, header.html,
> footer.html and so on).
> 
> 5) upload the parts that didn't have failures online.
> 
> The goal is to have the system running completely autonomous: this
> follows the Gump approach. [Sam, I'll need your help here, since I don't
> have an account on nagoya]
> 
>                                         - o -
> 
> Things to decide
> ================
> 
> 1) DTDs
> -------
> 
> The Cocoon project already has DTDs for 'documentation','change
> logs','todo list' and 'specifications'. They mainly use XHTML tags and
> are very easy to learn (they are an expansion of the original stylebook
> DTDs, so it's pretty easy to automatically adapt existing stylebook
> documents to this improved DTD, still keeping the simplicity we had
> before).
> 
> The rest of the required DTDs (description, news and ToC) must be agreed
> upon (i'll work on them in the next days)
> 
> 2) URIs
> -------
> 
> In order to achieve the future-compatible goal, we must come up with a
> guideline for URIs.
> 
> For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
> 2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
> into /cocoon1, creating a shit-load of broken links.
> 
> Two solutions where proposed (add your own if you have more)
> 
>  a) use version specific information and use mod_rewrite to adapt. for
> example
> 
>  xml.apache.org/cocoon/1.8.2/index.html
>  xml.apache.org/cocoon/2.0b1/index.html
>  xml.apache.org/cocoon/2.0b2/index.html
>  xml.apache.org/cocoon/2.0rc1/index.html
>  xml.apache.org/cocoon/2.0rc2/index.html
>  xml.apache.org/cocoon/2.0/index.html
> 
> then
> 
>  xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml
> 
> Problem is that while those versioned URI are never broken, the
> version-less redirected URI is changed for each release and doesn't
> reduce broken links. Also, it's probably easier to download the required
> version and look into the shipped docs and results in unnecessary big
> web sites.
> 
>  b) use semantic-meaningful yet version-less URIs
> 
>   xml.apache.org/cocoon/previous/ -> points to the previous generation
> docs
>   xml.apache.org/cocoon/ -> points to the latest docs
>   xml.apache.org/cocoon/next/ -> points to the next generation docs
> 
> which removes the need to have keep all the docs versions online, yet
> provides the ability to have both versions the latest one and the
> previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
> Cocoon 2.1-dev today). 
> 
> The problem of broken links isn't solved since everytime there is a
> transition, there is a chance of breaking previously established links
> if the docs ToC changes from one generation to the next.
> 
> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.
> 
> 4) CVS location and mail list discussions
> -----------------------------------------
> 
> Just like Gump which is not a subproject on its own, Forrest doesn't
> deserve that status neither as long as it remains a single-man show (and
> my experience tells me it will very likely remain so if the above goals
> are met)
> 
> At the same time, just like Gump, it requires a CVS space.
> 
> Possible places are:
> 
>  1) xml-site
>  2) xml-forrest
>  3) xml-site2
> 
> for mail list discussions, solutions are:
> 
>  1) general@xml.apache.org
>  2) cocoon-dev@xml.apache.org
>  3) site@xml.apache.org
>  4) forrest@xml.apache.org

Let's do this in xml-site or at xml-site2.   

> Please, add your comments/suggestions and your votes where a decision is
> required.
> 
> Thank you.
> 
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ----
> 

> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

["Theodore W. Leung" <tw...@sauria.com>]

On Sun, 2001-12-16 at 13:33, Stefano Mazzocchi wrote:
> [sorry for cross-post: this is a general issue, but I'd like the cocoon
> people to know what I'm doing so that they might give me a hand :)]
> 
> I started the effort that will, hopefully, bring us a much more useful
> documentation system for xml.apache.org and, hopefully, to the entire
> ASF, even if political and ego obstacles will get in the way.
> 
> I personally don't care: this effort is mainly to create a better
> documentation infrastructure following the goals outlined below. I
> started the Cocoon project three years ago exactly for this reason and
> now that has all the features I needed, I think I can attack the problem
> from a very wide angle. 
> 
> The site building system will be targetted toward xml.apache.org, but
> I'll keep a very broad perspective, making it possible to adapt the
> system to other apache.org projects with very few changes.
> 
> BIG DISCLAIMER: however, whether this happens or not, I personally don't
> care. For sure, don't count on me wasting my time on fighting about 'my
> DTD is better than yours' or 'my system is
> faster/smaller/cleaner/easier-to-use/more-extensible than yours'.
> 
> I'll come up with a system that works and then you guys will vote on
> what to do. I consider this an exercise to present full Cocoon
> potentials (that, objectively, beat the pants out of all the other
> systems used around Apache) but nothing more than this.
> 
>                                     - o -
> 
> Ok, now that I stated this, let's get into the effort goals.
> 
> GOALS
> -----
> 
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.
> 
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.
> 
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?
> 
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.
> 
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
> 
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.
> 
> 7) Extensibility, Flexibility, Modularity: web sites, just as software,
> are living entities that adapt on their environment. The build system
> must not restrict the ability to evolutionary extend the information
> architecture.
> 
> 8) URI Solidity and Future Compatibility: URIs are contracts between the
> publisher and the user. Human users have the ability to estimate the
> long-term validity of these contracts and 'route around' eventual broken
> links, while machine users do not. The goal is to come up with a system
> that allows to generate a web site with strong URIs.
> 
> 
> Design Decisions
> ----------------
> 
> staticity: even if I think that the availability of a dynamic publishing
> system would be beneficial, considering the web site load, the load of
> the apache machines and the state of the JVM for FreeBSD and the
> political problems behind all this, it's *must* easier (at least for
> now) to have a static version of the site batch-produced and then placed
> into the web-serving space.
+1
> automaticity: the site will be automatically generated out of files
> stored into CVS. The idea is to have GUMP-like nagging features that
> send email to the various mail lists using XML validation to estimate
> the 'integrity' of the docs placed.
+1
> For this reason, in honor of Sam Ruby's great work, and for the
> resonation with 'forest', thus a huge number of trees (i.e. XML files),
> I call this effort "Forrest".
> 
> I believe that together, Forrest and Gump, will help bringing apache
> quality one step up (moreover, as in the name, forrest wraps gump and
> will publish its generated data, providing more overall coherence)
> 
>                                         - o -
> 
> separation of concerns
> ----------------------
> 
> There are three concern islands, here is a list of their duties.
> 
> subproject
> ==========
> 
> each subproject should provide:
> 3.a) a 'description' file that includes information on the codebase, its
> description, its released versions, its CVS modules, its CVS tags, its
> mail lists and its documentations (yes, a subproject might have more
> than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
> [proposed filename: /description.xml]
>  
> 3.b) a 'committers info' file that includes information on the
> committers, along with a short bio, an email address and a picture of
> them. [proposed filename: /committers.xml]
> 
> 3.c) a 'change log' file that includes information on changes and
> software relases [proposed filename: /changes.xml]
> 
> 3.d) a 'todo list' file that includes the information on things to do
> and who volunteered for doing it [proposed filename: /todo.xml]
> 
> 3.e) a 'news' file that includes events and useful information that
> should be made available to the general public.
> 
> then, for each documentation (location is get from the description
> file):
> 
> 3.f) a 'table of content' that indicates the hierarchical sequence of
> the files and where to find them into the CVS repository (for each
> documentation). This is kept as a single file to allow document writers
> to maintain 'coherence' and visualize the entire part. This is
> equivalent to the stylebook book.xml file but with full nesting
> capabilities.
> 
> 3.e) the pages that componse the documentation (their location is get
> from the ToC file)
> 
> Log scanner
> ===========
> 
> The log scanner is a set of scripts that scan the logs from the CVS, the
> mail lists and the web site to gather information on:
> 
>  1) mail list activity (subscribers and messages)
>  2) web site activity (hits and downloads)
>  3) CVS activity (general commits, commits per person)
> 
> This scanner provides this information in a simple format that can be
> easily fed into the documentation building system.
> 
> Build system
> ============
> 
> The build system will:
> 
> 1) aggregate, filter and otherwise adapt the information collected from
> the various subprojects CVS modules, from the log scanner and from the
> GUMP run into static HTML files (for the browser pages), static PDF
> files (for print-friendly versions) and JPEG images (for graphs).
> 
> 2) generate navigation information in all the pages
> 
> 3) check validation of all the required XML files and send nag messages
> to the mail lists if failure occurs.
> 
> 4) generate httpd-related corollary files (.htaccess, header.html,
> footer.html and so on).
> 
> 5) upload the parts that didn't have failures online.
> 
> The goal is to have the system running completely autonomous: this
> follows the Gump approach. [Sam, I'll need your help here, since I don't
> have an account on nagoya]
> 
>                                         - o -
> 
> Things to decide
> ================
> 
> 1) DTDs
> -------
> 
> The Cocoon project already has DTDs for 'documentation','change
> logs','todo list' and 'specifications'. They mainly use XHTML tags and
> are very easy to learn (they are an expansion of the original stylebook
> DTDs, so it's pretty easy to automatically adapt existing stylebook
> documents to this improved DTD, still keeping the simplicity we had
> before).
> 
> The rest of the required DTDs (description, news and ToC) must be agreed
> upon (i'll work on them in the next days)
> 
> 2) URIs
> -------
> 
> In order to achieve the future-compatible goal, we must come up with a
> guideline for URIs.
> 
> For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
> 2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
> into /cocoon1, creating a shit-load of broken links.
> 
> Two solutions where proposed (add your own if you have more)
> 
>  a) use version specific information and use mod_rewrite to adapt. for
> example
> 
>  xml.apache.org/cocoon/1.8.2/index.html
>  xml.apache.org/cocoon/2.0b1/index.html
>  xml.apache.org/cocoon/2.0b2/index.html
>  xml.apache.org/cocoon/2.0rc1/index.html
>  xml.apache.org/cocoon/2.0rc2/index.html
>  xml.apache.org/cocoon/2.0/index.html
> 
> then
> 
>  xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml
> 
> Problem is that while those versioned URI are never broken, the
> version-less redirected URI is changed for each release and doesn't
> reduce broken links. Also, it's probably easier to download the required
> version and look into the shipped docs and results in unnecessary big
> web sites.
> 
>  b) use semantic-meaningful yet version-less URIs
> 
>   xml.apache.org/cocoon/previous/ -> points to the previous generation
> docs
>   xml.apache.org/cocoon/ -> points to the latest docs
>   xml.apache.org/cocoon/next/ -> points to the next generation docs
> 
> which removes the need to have keep all the docs versions online, yet
> provides the ability to have both versions the latest one and the
> previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
> Cocoon 2.1-dev today). 
> 
> The problem of broken links isn't solved since everytime there is a
> transition, there is a chance of breaking previously established links
> if the docs ToC changes from one generation to the next.
> 
> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.
> 
> 4) CVS location and mail list discussions
> -----------------------------------------
> 
> Just like Gump which is not a subproject on its own, Forrest doesn't
> deserve that status neither as long as it remains a single-man show (and
> my experience tells me it will very likely remain so if the above goals
> are met)
> 
> At the same time, just like Gump, it requires a CVS space.
> 
> Possible places are:
> 
>  1) xml-site
>  2) xml-forrest
>  3) xml-site2
> 
> for mail list discussions, solutions are:
> 
>  1) general@xml.apache.org
>  2) cocoon-dev@xml.apache.org
>  3) site@xml.apache.org
>  4) forrest@xml.apache.org

Let's do this in xml-site or at xml-site2.   

> Please, add your comments/suggestions and your votes where a decision is
> required.
> 
> Thank you.
> 
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ----
> 

> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

Carlos wrote:
> 
> Stefano:
> 
> Forrester looks great overall. I have a couple questions/suggestions.
> 
> Are you considering using drop down menus or somehow hiding the subsections
> on the main page for each project. In my experience, the more a users sees
> the more likely he/she is to get confused and loose track of where they are
> and what they were initially looking for.

Don't worry, these sort of basic usability concepts are well understood
and will be taken into consideration.

> It would be nice if, based on log analysis you could more things that are
> more relevant/have been searched for/requested the most. It might be done on
> a separate page or as part of the home page. This would make it easier for
> people to search for things that are the most frequently searched things on
> the website, with an eye on making things easier for the user.

Once Forrest is functional and collected data is available, I *hope*
that people will send me patches to turn that data more useful.

There will be a CVS module where you can download stuff and send diffs,
just like you'd do for any other project.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Carlos <ca...@cvc.edu>]

Stefano:

Forrester looks great overall. I have a couple questions/suggestions.

Are you considering using drop down menus or somehow hiding the subsections
on the main page for each project. In my experience, the more a users sees
the more likely he/she is to get confused and loose track of where they are
and what they were initially looking for.

It would be nice if, based on log analysis you could more things that are
more relevant/have been searched for/requested the most. It might be done on
a separate page or as part of the home page. This would make it easier for
people to search for things that are the most frequently searched things on
the website, with an eye on making things easier for the user.

Those are the questions I have. As I said at the top, the site looks great

Carlos


on 12/16/01 1:33 PM, Stefano Mazzocchi at stefano@apache.org wrote:

> [sorry for cross-post: this is a general issue, but I'd like the cocoon
> people to know what I'm doing so that they might give me a hand :)]
> 
> I started the effort that will, hopefully, bring us a much more useful
> documentation system for xml.apache.org and, hopefully, to the entire
> ASF, even if political and ego obstacles will get in the way.
> 
> I personally don't care: this effort is mainly to create a better
> documentation infrastructure following the goals outlined below. I
> started the Cocoon project three years ago exactly for this reason and
> now that has all the features I needed, I think I can attack the problem
> from a very wide angle.
> 
> The site building system will be targetted toward xml.apache.org, but
> I'll keep a very broad perspective, making it possible to adapt the
> system to other apache.org projects with very few changes.
> 
> BIG DISCLAIMER: however, whether this happens or not, I personally don't
> care. For sure, don't count on me wasting my time on fighting about 'my
> DTD is better than yours' or 'my system is
> faster/smaller/cleaner/easier-to-use/more-extensible than yours'.
> 
> I'll come up with a system that works and then you guys will vote on
> what to do. I consider this an exercise to present full Cocoon
> potentials (that, objectively, beat the pants out of all the other
> systems used around Apache) but nothing more than this.
> 
>                                   - o -
> 
> Ok, now that I stated this, let's get into the effort goals.
> 
> GOALS
> -----
> 
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.
> 
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.
> 
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?
> 
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.
> 
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
> 
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.
> 
> 7) Extensibility, Flexibility, Modularity: web sites, just as software,
> are living entities that adapt on their environment. The build system
> must not restrict the ability to evolutionary extend the information
> architecture.
> 
> 8) URI Solidity and Future Compatibility: URIs are contracts between the
> publisher and the user. Human users have the ability to estimate the
> long-term validity of these contracts and 'route around' eventual broken
> links, while machine users do not. The goal is to come up with a system
> that allows to generate a web site with strong URIs.
> 
> 
> Design Decisions
> ----------------
> 
> staticity: even if I think that the availability of a dynamic publishing
> system would be beneficial, considering the web site load, the load of
> the apache machines and the state of the JVM for FreeBSD and the
> political problems behind all this, it's *must* easier (at least for
> now) to have a static version of the site batch-produced and then placed
> into the web-serving space.
> 
> automaticity: the site will be automatically generated out of files
> stored into CVS. The idea is to have GUMP-like nagging features that
> send email to the various mail lists using XML validation to estimate
> the 'integrity' of the docs placed.
> 
> For this reason, in honor of Sam Ruby's great work, and for the
> resonation with 'forest', thus a huge number of trees (i.e. XML files),
> I call this effort "Forrest".
> 
> I believe that together, Forrest and Gump, will help bringing apache
> quality one step up (moreover, as in the name, forrest wraps gump and
> will publish its generated data, providing more overall coherence)
> 
>                                       - o -
> 
> separation of concerns
> ----------------------
> 
> There are three concern islands, here is a list of their duties.
> 
> subproject
> ==========
> 
> each subproject should provide:
> 
> 3.a) a 'description' file that includes information on the codebase, its
> description, its released versions, its CVS modules, its CVS tags, its
> mail lists and its documentations (yes, a subproject might have more
> than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
> [proposed filename: /description.xml]
> 
> 3.b) a 'committers info' file that includes information on the
> committers, along with a short bio, an email address and a picture of
> them. [proposed filename: /committers.xml]
> 
> 3.c) a 'change log' file that includes information on changes and
> software relases [proposed filename: /changes.xml]
> 
> 3.d) a 'todo list' file that includes the information on things to do
> and who volunteered for doing it [proposed filename: /todo.xml]
> 
> 3.e) a 'news' file that includes events and useful information that
> should be made available to the general public.
> 
> then, for each documentation (location is get from the description
> file):
> 
> 3.f) a 'table of content' that indicates the hierarchical sequence of
> the files and where to find them into the CVS repository (for each
> documentation). This is kept as a single file to allow document writers
> to maintain 'coherence' and visualize the entire part. This is
> equivalent to the stylebook book.xml file but with full nesting
> capabilities.
> 
> 3.e) the pages that componse the documentation (their location is get
> from the ToC file)
> 
> Log scanner
> ===========
> 
> The log scanner is a set of scripts that scan the logs from the CVS, the
> mail lists and the web site to gather information on:
> 
> 1) mail list activity (subscribers and messages)
> 2) web site activity (hits and downloads)
> 3) CVS activity (general commits, commits per person)
> 
> This scanner provides this information in a simple format that can be
> easily fed into the documentation building system.
> 
> Build system
> ============
> 
> The build system will:
> 
> 1) aggregate, filter and otherwise adapt the information collected from
> the various subprojects CVS modules, from the log scanner and from the
> GUMP run into static HTML files (for the browser pages), static PDF
> files (for print-friendly versions) and JPEG images (for graphs).
> 
> 2) generate navigation information in all the pages
> 
> 3) check validation of all the required XML files and send nag messages
> to the mail lists if failure occurs.
> 
> 4) generate httpd-related corollary files (.htaccess, header.html,
> footer.html and so on).
> 
> 5) upload the parts that didn't have failures online.
> 
> The goal is to have the system running completely autonomous: this
> follows the Gump approach. [Sam, I'll need your help here, since I don't
> have an account on nagoya]
> 
>                                       - o -
> 
> Things to decide
> ================
> 
> 1) DTDs
> -------
> 
> The Cocoon project already has DTDs for 'documentation','change
> logs','todo list' and 'specifications'. They mainly use XHTML tags and
> are very easy to learn (they are an expansion of the original stylebook
> DTDs, so it's pretty easy to automatically adapt existing stylebook
> documents to this improved DTD, still keeping the simplicity we had
> before).
> 
> The rest of the required DTDs (description, news and ToC) must be agreed
> upon (i'll work on them in the next days)
> 
> 2) URIs
> -------
> 
> In order to achieve the future-compatible goal, we must come up with a
> guideline for URIs.
> 
> For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
> 2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
> into /cocoon1, creating a shit-load of broken links.
> 
> Two solutions where proposed (add your own if you have more)
> 
> a) use version specific information and use mod_rewrite to adapt. for
> example
> 
> xml.apache.org/cocoon/1.8.2/index.html
> xml.apache.org/cocoon/2.0b1/index.html
> xml.apache.org/cocoon/2.0b2/index.html
> xml.apache.org/cocoon/2.0rc1/index.html
> xml.apache.org/cocoon/2.0rc2/index.html
> xml.apache.org/cocoon/2.0/index.html
> 
> then
> 
> xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml
> 
> Problem is that while those versioned URI are never broken, the
> version-less redirected URI is changed for each release and doesn't
> reduce broken links. Also, it's probably easier to download the required
> version and look into the shipped docs and results in unnecessary big
> web sites.
> 
> b) use semantic-meaningful yet version-less URIs
> 
> xml.apache.org/cocoon/previous/ -> points to the previous generation
> docs
> xml.apache.org/cocoon/ -> points to the latest docs
> xml.apache.org/cocoon/next/ -> points to the next generation docs
> 
> which removes the need to have keep all the docs versions online, yet
> provides the ability to have both versions the latest one and the
> previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
> Cocoon 2.1-dev today).
> 
> The problem of broken links isn't solved since everytime there is a
> transition, there is a chance of breaking previously established links
> if the docs ToC changes from one generation to the next.
> 
> 3) layout
> ---------
> 
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
> 
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k. 
> 
> Feedback, suggestions and criticisms are appreciated.
> 
> 4) CVS location and mail list discussions
> -----------------------------------------
> 
> Just like Gump which is not a subproject on its own, Forrest doesn't
> deserve that status neither as long as it remains a single-man show (and
> my experience tells me it will very likely remain so if the above goals
> are met)
> 
> At the same time, just like Gump, it requires a CVS space.
> 
> Possible places are:
> 
> 1) xml-site
> 2) xml-forrest
> 3) xml-site2
> 
> for mail list discussions, solutions are:
> 
> 1) general@xml.apache.org
> 2) cocoon-dev@xml.apache.org
> 3) site@xml.apache.org
> 4) forrest@xml.apache.org
> 
> Please, add your comments/suggestions and your votes where a decision is
> required.
> 
> Thank you.

-- 
---+ Carlos Araya
 P | WebCT Administrator/Trainer
 _ | California Virtual Campus, Region 1
 G | C/O De Anza College
---+ 21250 Stevens Creek Blvd.,
Cupertino, CA 95014

Email:      carlos@cvc.edu
Phone:      408.257.0420
Fax:        408.255.4406
Web:        http://www.cvc1.org/ (work)
            http://www.silverwolf-net.net/ (personal)

"Paradoxically, a refusal to 'put a monetary value on life' means that
life is often undervalued."
-- Artificial Intelligence: A Modern Approach




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Stefano Mazzocchi <st...@apache.org>]

giacomo wrote:
> 
> On Sun, 16 Dec 2001, Stefano Mazzocchi wrote:
> 
> I have some experience in using cocoon to generate html sites and pdf
> books with full validation turned on. So I might be of help in this
> concern (yes, cocoon is able to do that out of the box with support for
> CATALOG mappings to overcome the hassle of SystemID pointing into the
> file system instead of using  http URLs).
> 
> Another point is (yes, guys, it comes again) shouldn't we move to a
> more "official" DTD for our docs?

I'm going to come up with the DTD discussion RSN. Please, hold it for
now.

> The Avalon project already has parts
> of their documents written in DocBook as well as XSLT stylesheets to
> 
>         1. transform DocBook to html and pdf (addmittedly only a subset
>            of DocBook)
>         2. convert the cocoon DTDs you've mentioned somewhere below
>            to the DocBook DTD (for legacy reasons :).
> 
> In a documentation build system based on cocoon I'm using I've choosen
> an evolutionary approach to support various DocBook elements by adding a
> XSLT template like this:
> 
>  <xsl:template match="node()" priority=".-1">
>    <xsl:message>
>      THE ELEMENT <xsl:value-of select="name(.)"> ISN'T YET SUPPORTED
>    </xsl:message>
>    <xsl:copy>
>      <xsl:apply-templates/>
>    <xsl:copy>
>  </xsl:template>
> 
>  <xsl:template match="@*" priority="-1">
>    <xsl:copy>
>      <xsl:apply-templates/>
>    <xsl:copy>
>  </xsl:template>
> 
> These templates lead to show during the build process each element used
> in the xdocs without explicit support made available.

That's a good suggestion, thanks.

The DTD dicussion will be next.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[Andy Clark <an...@apache.org>]

giacomo wrote:
> Another point is (yes, guys, it comes again) shouldn't we move to a
> more "official" DTD for our docs? The Avalon project already has parts
> of their documents written in DocBook as well as XSLT stylesheets to

+1 for DocBook (or a subset)

-- 
Andy Clark * andyc@apache.org
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[giacomo <gi...@apache.org>]

On Sun, 16 Dec 2001, Stefano Mazzocchi wrote:

I have some experience in using cocoon to generate html sites and pdf
books with full validation turned on. So I might be of help in this
concern (yes, cocoon is able to do that out of the box with support for
CATALOG mappings to overcome the hassle of SystemID pointing into the
file system instead of using  http URLs).

Another point is (yes, guys, it comes again) shouldn't we move to a
more "official" DTD for our docs? The Avalon project already has parts
of their documents written in DocBook as well as XSLT stylesheets to

        1. transform DocBook to html and pdf (addmittedly only a subset
           of DocBook)
	2. convert the cocoon DTDs you've mentioned somewhere below
           to the DocBook DTD (for legacy reasons :).

In a documentation build system based on cocoon I'm using I've choosen
an evolutionary approach to support various DocBook elements by adding a
XSLT template like this:

 <xsl:template match="node()" priority=".-1">
   <xsl:message>
     THE ELEMENT <xsl:value-of select="name(.)"> ISN'T YET SUPPORTED
   </xsl:message>
   <xsl:copy>
     <xsl:apply-templates/>
   <xsl:copy>
 </xsl:template>

 <xsl:template match="@*" priority="-1">
   <xsl:copy>
     <xsl:apply-templates/>
   <xsl:copy>
 </xsl:template>

These templates lead to show during the build process each element used
in the xdocs without explicit support made available.

Giacomo

> [sorry for cross-post: this is a general issue, but I'd like the cocoon
> people to know what I'm doing so that they might give me a hand :)]
>
> I started the effort that will, hopefully, bring us a much more useful
> documentation system for xml.apache.org and, hopefully, to the entire
> ASF, even if political and ego obstacles will get in the way.
>
> I personally don't care: this effort is mainly to create a better
> documentation infrastructure following the goals outlined below. I
> started the Cocoon project three years ago exactly for this reason and
> now that has all the features I needed, I think I can attack the problem
> from a very wide angle.
>
> The site building system will be targetted toward xml.apache.org, but
> I'll keep a very broad perspective, making it possible to adapt the
> system to other apache.org projects with very few changes.
>
> BIG DISCLAIMER: however, whether this happens or not, I personally don't
> care. For sure, don't count on me wasting my time on fighting about 'my
> DTD is better than yours' or 'my system is
> faster/smaller/cleaner/easier-to-use/more-extensible than yours'.
>
> I'll come up with a system that works and then you guys will vote on
> what to do. I consider this an exercise to present full Cocoon
> potentials (that, objectively, beat the pants out of all the other
> systems used around Apache) but nothing more than this.
>
>                                     - o -
>
> Ok, now that I stated this, let's get into the effort goals.
>
> GOALS
> -----
>
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.
>
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.
>
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?
>
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.
>
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
>
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.
>
> 7) Extensibility, Flexibility, Modularity: web sites, just as software,
> are living entities that adapt on their environment. The build system
> must not restrict the ability to evolutionary extend the information
> architecture.
>
> 8) URI Solidity and Future Compatibility: URIs are contracts between the
> publisher and the user. Human users have the ability to estimate the
> long-term validity of these contracts and 'route around' eventual broken
> links, while machine users do not. The goal is to come up with a system
> that allows to generate a web site with strong URIs.
>
>
> Design Decisions
> ----------------
>
> staticity: even if I think that the availability of a dynamic publishing
> system would be beneficial, considering the web site load, the load of
> the apache machines and the state of the JVM for FreeBSD and the
> political problems behind all this, it's *must* easier (at least for
> now) to have a static version of the site batch-produced and then placed
> into the web-serving space.
>
> automaticity: the site will be automatically generated out of files
> stored into CVS. The idea is to have GUMP-like nagging features that
> send email to the various mail lists using XML validation to estimate
> the 'integrity' of the docs placed.
>
> For this reason, in honor of Sam Ruby's great work, and for the
> resonation with 'forest', thus a huge number of trees (i.e. XML files),
> I call this effort "Forrest".
>
> I believe that together, Forrest and Gump, will help bringing apache
> quality one step up (moreover, as in the name, forrest wraps gump and
> will publish its generated data, providing more overall coherence)
>
>                                         - o -
>
> separation of concerns
> ----------------------
>
> There are three concern islands, here is a list of their duties.
>
> subproject
> ==========
>
> each subproject should provide:
>
> 3.a) a 'description' file that includes information on the codebase, its
> description, its released versions, its CVS modules, its CVS tags, its
> mail lists and its documentations (yes, a subproject might have more
> than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
> [proposed filename: /description.xml]
>
> 3.b) a 'committers info' file that includes information on the
> committers, along with a short bio, an email address and a picture of
> them. [proposed filename: /committers.xml]
>
> 3.c) a 'change log' file that includes information on changes and
> software relases [proposed filename: /changes.xml]
>
> 3.d) a 'todo list' file that includes the information on things to do
> and who volunteered for doing it [proposed filename: /todo.xml]
>
> 3.e) a 'news' file that includes events and useful information that
> should be made available to the general public.
>
> then, for each documentation (location is get from the description
> file):
>
> 3.f) a 'table of content' that indicates the hierarchical sequence of
> the files and where to find them into the CVS repository (for each
> documentation). This is kept as a single file to allow document writers
> to maintain 'coherence' and visualize the entire part. This is
> equivalent to the stylebook book.xml file but with full nesting
> capabilities.
>
> 3.e) the pages that componse the documentation (their location is get
> from the ToC file)
>
> Log scanner
> ===========
>
> The log scanner is a set of scripts that scan the logs from the CVS, the
> mail lists and the web site to gather information on:
>
>  1) mail list activity (subscribers and messages)
>  2) web site activity (hits and downloads)
>  3) CVS activity (general commits, commits per person)
>
> This scanner provides this information in a simple format that can be
> easily fed into the documentation building system.
>
> Build system
> ============
>
> The build system will:
>
> 1) aggregate, filter and otherwise adapt the information collected from
> the various subprojects CVS modules, from the log scanner and from the
> GUMP run into static HTML files (for the browser pages), static PDF
> files (for print-friendly versions) and JPEG images (for graphs).
>
> 2) generate navigation information in all the pages
>
> 3) check validation of all the required XML files and send nag messages
> to the mail lists if failure occurs.
>
> 4) generate httpd-related corollary files (.htaccess, header.html,
> footer.html and so on).
>
> 5) upload the parts that didn't have failures online.
>
> The goal is to have the system running completely autonomous: this
> follows the Gump approach. [Sam, I'll need your help here, since I don't
> have an account on nagoya]
>
>                                         - o -
>
> Things to decide
> ================
>
> 1) DTDs
> -------
>
> The Cocoon project already has DTDs for 'documentation','change
> logs','todo list' and 'specifications'. They mainly use XHTML tags and
> are very easy to learn (they are an expansion of the original stylebook
> DTDs, so it's pretty easy to automatically adapt existing stylebook
> documents to this improved DTD, still keeping the simplicity we had
> before).
>
> The rest of the required DTDs (description, news and ToC) must be agreed
> upon (i'll work on them in the next days)
>
> 2) URIs
> -------
>
> In order to achieve the future-compatible goal, we must come up with a
> guideline for URIs.
>
> For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
> 2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
> into /cocoon1, creating a shit-load of broken links.
>
> Two solutions where proposed (add your own if you have more)
>
>  a) use version specific information and use mod_rewrite to adapt. for
> example
>
>  xml.apache.org/cocoon/1.8.2/index.html
>  xml.apache.org/cocoon/2.0b1/index.html
>  xml.apache.org/cocoon/2.0b2/index.html
>  xml.apache.org/cocoon/2.0rc1/index.html
>  xml.apache.org/cocoon/2.0rc2/index.html
>  xml.apache.org/cocoon/2.0/index.html
>
> then
>
>  xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml
>
> Problem is that while those versioned URI are never broken, the
> version-less redirected URI is changed for each release and doesn't
> reduce broken links. Also, it's probably easier to download the required
> version and look into the shipped docs and results in unnecessary big
> web sites.
>
>  b) use semantic-meaningful yet version-less URIs
>
>   xml.apache.org/cocoon/previous/ -> points to the previous generation
> docs
>   xml.apache.org/cocoon/ -> points to the latest docs
>   xml.apache.org/cocoon/next/ -> points to the next generation docs
>
> which removes the need to have keep all the docs versions online, yet
> provides the ability to have both versions the latest one and the
> previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
> Cocoon 2.1-dev today).
>
> The problem of broken links isn't solved since everytime there is a
> transition, there is a chance of breaking previously established links
> if the docs ToC changes from one generation to the next.
>
> 3) layout
> ---------
>
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
>
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k.
>
> Feedback, suggestions and criticisms are appreciated.
>
> 4) CVS location and mail list discussions
> -----------------------------------------
>
> Just like Gump which is not a subproject on its own, Forrest doesn't
> deserve that status neither as long as it remains a single-man show (and
> my experience tells me it will very likely remain so if the above goals
> are met)
>
> At the same time, just like Gump, it requires a CVS space.
>
> Possible places are:
>
>  1) xml-site
>  2) xml-forrest
>  3) xml-site2
>
> for mail list discussions, solutions are:
>
>  1) general@xml.apache.org
>  2) cocoon-dev@xml.apache.org
>  3) site@xml.apache.org
>  4) forrest@xml.apache.org
>
> Please, add your comments/suggestions and your votes where a decision is
> required.
>
> Thank you.
>
>


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: Forrest (a.k.a. xml.apache.org 2.0)

[giacomo <gi...@apache.org>]

On Sun, 16 Dec 2001, Stefano Mazzocchi wrote:

I have some experience in using cocoon to generate html sites and pdf
books with full validation turned on. So I might be of help in this
concern (yes, cocoon is able to do that out of the box with support for
CATALOG mappings to overcome the hassle of SystemID pointing into the
file system instead of using  http URLs).

Another point is (yes, guys, it comes again) shouldn't we move to a
more "official" DTD for our docs? The Avalon project already has parts
of their documents written in DocBook as well as XSLT stylesheets to

        1. transform DocBook to html and pdf (addmittedly only a subset
           of DocBook)
	2. convert the cocoon DTDs you've mentioned somewhere below
           to the DocBook DTD (for legacy reasons :).

In a documentation build system based on cocoon I'm using I've choosen
an evolutionary approach to support various DocBook elements by adding a
XSLT template like this:

 <xsl:template match="node()" priority=".-1">
   <xsl:message>
     THE ELEMENT <xsl:value-of select="name(.)"> ISN'T YET SUPPORTED
   </xsl:message>
   <xsl:copy>
     <xsl:apply-templates/>
   <xsl:copy>
 </xsl:template>

 <xsl:template match="@*" priority="-1">
   <xsl:copy>
     <xsl:apply-templates/>
   <xsl:copy>
 </xsl:template>

These templates lead to show during the build process each element used
in the xdocs without explicit support made available.

Giacomo

> [sorry for cross-post: this is a general issue, but I'd like the cocoon
> people to know what I'm doing so that they might give me a hand :)]
>
> I started the effort that will, hopefully, bring us a much more useful
> documentation system for xml.apache.org and, hopefully, to the entire
> ASF, even if political and ego obstacles will get in the way.
>
> I personally don't care: this effort is mainly to create a better
> documentation infrastructure following the goals outlined below. I
> started the Cocoon project three years ago exactly for this reason and
> now that has all the features I needed, I think I can attack the problem
> from a very wide angle.
>
> The site building system will be targetted toward xml.apache.org, but
> I'll keep a very broad perspective, making it possible to adapt the
> system to other apache.org projects with very few changes.
>
> BIG DISCLAIMER: however, whether this happens or not, I personally don't
> care. For sure, don't count on me wasting my time on fighting about 'my
> DTD is better than yours' or 'my system is
> faster/smaller/cleaner/easier-to-use/more-extensible than yours'.
>
> I'll come up with a system that works and then you guys will vote on
> what to do. I consider this an exercise to present full Cocoon
> potentials (that, objectively, beat the pants out of all the other
> systems used around Apache) but nothing more than this.
>
>                                     - o -
>
> Ok, now that I stated this, let's get into the effort goals.
>
> GOALS
> -----
>
> 1) Speed: current xml.apache.org is slow. Empirical studies on learning
> processes indicate that if a page takes more than 10 seconds on a 56Kbs
> modem, the cognitive experience is degrated.
>
> 2) Coherence: current xml.apache.org is extremely incoherent. Again,
> it's easy to understand that lack of coherence between subprojects docs
> is perceived (and sometimes reflects!) lack of cooperation.
>
> 3) Navigation: the navigation experience on current xml.apache.org is a
> nightmare. There is no way to perceive the basic elements of spatial
> navigation: where am I? where can I go? how do I go back? how do I go
> there?
>
> 4) Depth: the current xml.apache.org page layout forces a flat hierarchy
> of levels. The current Cocoon documentation somewhat extends this, but
> the visual look doesn't reflect the notion. Visual codes are extremely
> important to allow a easy and immediate navigation even at the deepest
> level.
>
> 5) Usefulness: xml.apache.org contains powerful software but it's not
> powerful in itself. It should be a window on the information useful for
> both users and developers, along with friendly behavior, such as
> print-friendly versions of the single pages and of the whole
> per-subproject documentation, pagination of long articles,
> site-restricted search, graphs of project-related data and so on.
>
> 6) Simplicity: xml.apache.org is done by volunteers, on all levels.
> Nobody is directly paid to do this. Not even myself. So, if the above
> goals are met, but the system is not simple and immediate to use for
> those who have to maintain and update the information, the result is
> void over a short period of time.
>
> 7) Extensibility, Flexibility, Modularity: web sites, just as software,
> are living entities that adapt on their environment. The build system
> must not restrict the ability to evolutionary extend the information
> architecture.
>
> 8) URI Solidity and Future Compatibility: URIs are contracts between the
> publisher and the user. Human users have the ability to estimate the
> long-term validity of these contracts and 'route around' eventual broken
> links, while machine users do not. The goal is to come up with a system
> that allows to generate a web site with strong URIs.
>
>
> Design Decisions
> ----------------
>
> staticity: even if I think that the availability of a dynamic publishing
> system would be beneficial, considering the web site load, the load of
> the apache machines and the state of the JVM for FreeBSD and the
> political problems behind all this, it's *must* easier (at least for
> now) to have a static version of the site batch-produced and then placed
> into the web-serving space.
>
> automaticity: the site will be automatically generated out of files
> stored into CVS. The idea is to have GUMP-like nagging features that
> send email to the various mail lists using XML validation to estimate
> the 'integrity' of the docs placed.
>
> For this reason, in honor of Sam Ruby's great work, and for the
> resonation with 'forest', thus a huge number of trees (i.e. XML files),
> I call this effort "Forrest".
>
> I believe that together, Forrest and Gump, will help bringing apache
> quality one step up (moreover, as in the name, forrest wraps gump and
> will publish its generated data, providing more overall coherence)
>
>                                         - o -
>
> separation of concerns
> ----------------------
>
> There are three concern islands, here is a list of their duties.
>
> subproject
> ==========
>
> each subproject should provide:
>
> 3.a) a 'description' file that includes information on the codebase, its
> description, its released versions, its CVS modules, its CVS tags, its
> mail lists and its documentations (yes, a subproject might have more
> than one, think of Xerces1/Xerces2, Xalan1/Xalan2, Cocoon1/Cocoon2).
> [proposed filename: /description.xml]
>
> 3.b) a 'committers info' file that includes information on the
> committers, along with a short bio, an email address and a picture of
> them. [proposed filename: /committers.xml]
>
> 3.c) a 'change log' file that includes information on changes and
> software relases [proposed filename: /changes.xml]
>
> 3.d) a 'todo list' file that includes the information on things to do
> and who volunteered for doing it [proposed filename: /todo.xml]
>
> 3.e) a 'news' file that includes events and useful information that
> should be made available to the general public.
>
> then, for each documentation (location is get from the description
> file):
>
> 3.f) a 'table of content' that indicates the hierarchical sequence of
> the files and where to find them into the CVS repository (for each
> documentation). This is kept as a single file to allow document writers
> to maintain 'coherence' and visualize the entire part. This is
> equivalent to the stylebook book.xml file but with full nesting
> capabilities.
>
> 3.e) the pages that componse the documentation (their location is get
> from the ToC file)
>
> Log scanner
> ===========
>
> The log scanner is a set of scripts that scan the logs from the CVS, the
> mail lists and the web site to gather information on:
>
>  1) mail list activity (subscribers and messages)
>  2) web site activity (hits and downloads)
>  3) CVS activity (general commits, commits per person)
>
> This scanner provides this information in a simple format that can be
> easily fed into the documentation building system.
>
> Build system
> ============
>
> The build system will:
>
> 1) aggregate, filter and otherwise adapt the information collected from
> the various subprojects CVS modules, from the log scanner and from the
> GUMP run into static HTML files (for the browser pages), static PDF
> files (for print-friendly versions) and JPEG images (for graphs).
>
> 2) generate navigation information in all the pages
>
> 3) check validation of all the required XML files and send nag messages
> to the mail lists if failure occurs.
>
> 4) generate httpd-related corollary files (.htaccess, header.html,
> footer.html and so on).
>
> 5) upload the parts that didn't have failures online.
>
> The goal is to have the system running completely autonomous: this
> follows the Gump approach. [Sam, I'll need your help here, since I don't
> have an account on nagoya]
>
>                                         - o -
>
> Things to decide
> ================
>
> 1) DTDs
> -------
>
> The Cocoon project already has DTDs for 'documentation','change
> logs','todo list' and 'specifications'. They mainly use XHTML tags and
> are very easy to learn (they are an expansion of the original stylebook
> DTDs, so it's pretty easy to automatically adapt existing stylebook
> documents to this improved DTD, still keeping the simplicity we had
> before).
>
> The rest of the required DTDs (description, news and ToC) must be agreed
> upon (i'll work on them in the next days)
>
> 2) URIs
> -------
>
> In order to achieve the future-compatible goal, we must come up with a
> guideline for URIs.
>
> For example, the Cocoon project had /cocoon and /cocoon2, then Cocoon
> 2.0 was released final and we moved /cocoon2 into /cocoon and /cocoon
> into /cocoon1, creating a shit-load of broken links.
>
> Two solutions where proposed (add your own if you have more)
>
>  a) use version specific information and use mod_rewrite to adapt. for
> example
>
>  xml.apache.org/cocoon/1.8.2/index.html
>  xml.apache.org/cocoon/2.0b1/index.html
>  xml.apache.org/cocoon/2.0b2/index.html
>  xml.apache.org/cocoon/2.0rc1/index.html
>  xml.apache.org/cocoon/2.0rc2/index.html
>  xml.apache.org/cocoon/2.0/index.html
>
> then
>
>  xml.apache.org/cocoon/ -> xml.apache.org/cocoon/2.0/index.hml
>
> Problem is that while those versioned URI are never broken, the
> version-less redirected URI is changed for each release and doesn't
> reduce broken links. Also, it's probably easier to download the required
> version and look into the shipped docs and results in unnecessary big
> web sites.
>
>  b) use semantic-meaningful yet version-less URIs
>
>   xml.apache.org/cocoon/previous/ -> points to the previous generation
> docs
>   xml.apache.org/cocoon/ -> points to the latest docs
>   xml.apache.org/cocoon/next/ -> points to the next generation docs
>
> which removes the need to have keep all the docs versions online, yet
> provides the ability to have both versions the latest one and the
> previous generation (for Cocoon would be Cocoon 1.8.2, Cocoon 2.0,
> Cocoon 2.1-dev today).
>
> The problem of broken links isn't solved since everytime there is a
> transition, there is a chance of breaking previously established links
> if the docs ToC changes from one generation to the next.
>
> 3) layout
> ---------
>
> The layout previously proposed on this list was a solution to the speed
> problem but I couldn't adapt it to the depth needs identified in the
> rest of the goals.
>
> So, I resurrected my rusty web design skills and came up with the layout
> you find attached. I've tested it on IE 5.5, NS 4.78 and Moz 0.9.5 on
> win2k.
>
> Feedback, suggestions and criticisms are appreciated.
>
> 4) CVS location and mail list discussions
> -----------------------------------------
>
> Just like Gump which is not a subproject on its own, Forrest doesn't
> deserve that status neither as long as it remains a single-man show (and
> my experience tells me it will very likely remain so if the above goals
> are met)
>
> At the same time, just like Gump, it requires a CVS space.
>
> Possible places are:
>
>  1) xml-site
>  2) xml-forrest
>  3) xml-site2
>
> for mail list discussions, solutions are:
>
>  1) general@xml.apache.org
>  2) cocoon-dev@xml.apache.org
>  3) site@xml.apache.org
>  4) forrest@xml.apache.org
>
> Please, add your comments/suggestions and your votes where a decision is
> required.
>
> Thank you.
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org