Re: -1 to Anakia [ or why the website is broken ]

[Ted Leung <tw...@sauria.com>]

The existing xml policy is "eat your own dogfood".

The current reality is that our dogfood (Stylebook) has gone bad.  There
are a variety of reasons for this, none of which really matter because they
are history.   We need a replacement.  Here are the criteria that a
replacement
need to satisfy IMHO:

1. It needs to be an actively maintained project - bugs need to be fixed and
questions
need to get answered.
2. It needs to have an XML input format - we must eat our own dogfood.
3. It needs to be straightforward to learn and operate -  any committer can
update the documentation or regenerate the website.
4. It needs to be accessible to non-programmers - so that technical writer
type folks can
contribute to documentation.
5. Performance is a non-criterion, because we may have to generate the
content off-line.
6. It needs to be possible for a user who downloads a build to somewhat
easily build the
docs.   From this follow that someone shouldn't need to download a zillion
packages just
to build the docs.  It's bad enough that they have to get stylebook now.
7. If we can use existing standards for stuff like this, we should.  Just
because Apache has 15
different templating systems doesn't mean we should use them all.

The next  problem is that the procedure for updating / maintaining the site
is tied up as folklore
in people's heads.  This needs to be clearly documented.  A good place to do
this would be on
the site.   Even better would be for this process to be automated as part of
a release build.

The problem after that is that the current site layout is too bandwidth
intensive.

Here's where I think we are on this (calling it a plan would be too strong):

Donald Ball has been working on getting the current site layout working on
Cocoon2.  Once he
does this we can talk about documenting/automating the site update process.
And thanks to
Donald for taking the time to do this!

As far as I know no one is working on fixing the site layout.  I think that
perhaps we ought to have a
contest for the site design.

If we want to change what we're doing that's fine.  But let's explicitly
have the discussion to do so.
If X2 and Axis are out of spec, then there's no point in changing them until
we agree on what we're
going to do to fix up the site.   If Jason needs something to do for short
term, I'd say just check in
the html.  I'm sympathetic to the desire to use a familiar tool.  I'm
looking at having to learn C2 also.

The site is in pretty bad shape, and it's high on my list of things that
need to get done soon.   Right
now the site is too hard to change, which means it isn't getting changed,
which means that there's
a whole bunch of info that people ought to have access to that they don't.

Ted

----- Original Message -----
From: "Sam Ruby" <ru...@us.ibm.com>
To: <ge...@xml.apache.org>
Sent: Friday, July 13, 2001 1:57 PM
Subject: Re: -1 to Anakia


> Scott Boag wrote:
> >
> > Hi Kids.  I hate to rain on the parade, but I think it would look pretty
> > funny to use Anakia instead of XSLT for the Xalan project.
>
> I don't believe that anybody suggested that Xalan use Anakia.
>
> There are several threads going on here.  IMHO:
>
> 1) Stylebook can be configured to use virtually any layout desired, but
the
> one chosen by the XML project is too graphics heavy.
>
> 2) Stylebook itself is not exactly maintained (Cocoon2 has been
threatening
> to replace it for ever)
>
> 3) The process for actually generating the site using stylebook is
> cumbersome at best.  I find that I get a wierd error which mysteriously
> goes away if I delete a specific cvs directory.  And the process of
knowing
> what generated files to check in is very error prone.
>
>  = = = =
>
> For reference, the jakarta policy, loosely paraphrased, is to allow each
> subproject autonomy in determing HOW they generate their web site as long
> as they conform to the look and feel of Jakarta.  That would be fine to
me,
> except for #1 above.
>
> What we need is a complete overhaul, top to bottom.  Meanwhile, telling
new
> subprojects that they must use stylebook and the current look and feel
> seems counterproductive to me.  And I can tell you that xerces2 and axis
> are completely out of spec...
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> 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: -1 to Anakia [ or why the website is broken ]

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

One important thing I forgot mention about the method below: It is all
managed by a single webapp.

In other words, say you have a tomcat server with several contexts. Each of
these contexts would be managed by the "master" context.  Users going to the
actual site (on the dev server) would see the site as usual. Users going to
the master site(on the dev server) would be asked to log in (basic or form
authentication) and select the site (one of the other webapps) they want to
edit.

----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: <ge...@xml.apache.org>
Sent: Saturday, July 14, 2001 7:50 AM
Subject: Re: -1 to Anakia [ or why the website is broken ]


> are you guys talking about xml.apache.org? apache.org?
>
> > 2. It needs to have an XML input format - we must eat our own dogfood.
>
> this is a given, right?
>
> > 3. It needs to be straightforward to learn and operate -  any committer
> can
> > update the documentation or regenerate the website.
>
> I don't think you want that, you want the ability to push a particular
page
> or folder (including subfolders) live from the QA server -- maybe. This
> should actually be part of the workflow:
> - writer checks a box on some gui to give their ok it should be promoted
to
> qa (whoever that is, but there should be someone...)
>  - qa checks a box (part of their qa system?--extra work) which indicates
it
> is ready to go live (or perhaps this pushes it live?).
> - Meta-info, including workflow staus, information about the folders,
pages,
> general site structure and some layout info is all held in a DB or  in a
> simple XML file under WEB-INF/xml/.
> ---- This is updated through a gui or direct editing/validating of the XML
> document by the person making the content.
> - Then daily, weekly this "config" file is read and the site is generated
> with xalan's redirect extension and XSL.
>
> > 4. It needs to be accessible to non-programmers - so that technical
writer
> > type folks can
> > contribute to documentation.
>
> The content needs to be TOTALLY separate from the presentation -- don't
use
> cocoon.  Content should be kept pure. The system should act on the
content.
> The content should just do what it is told, it should not do the telling.
> This would need to be another workflow issue if content was submitted from
> non-technical people who did not know anything about cocoon. And what
about
> the next guy? Will they have to do a transformation to clean up the XML?
> Why?
>
> Given pure content, the writer just needs to produce a simple docbook xml
> document (don't tell me this is hard, especially with GUI editors that are
> out now - in fact I have made/making a wysiwig tool... :).
> Generally:
> - some users can create folders
> - some have the ability to upload a plain text *.xml document or edit
> through web-front-end
> ---- true content - that is, the pure transferrable, resuable content
> ---- floater content - that is, content that could float anywhere on the
> page (according to the XSLT) and most likely would appear on more than one
> page (e.g. "Check out Xalan3 beta! - blah blah blah")
> - they can create  or assign xml to a particular page(s) (there are ways
to
> make this painless to the user)
>
> voila, you have a page at next scheduled generation or perhaps there is a
> trigger that allows a FEW (1?) people the ability to push content live
> outside of the regular schedule (daily, weekly, whatever)
>
> > As far as I know no one is working on fixing the site layout.  I think
> that
> > perhaps we ought to have a
> > contest for the site design.
>
> that would be fun!
>
>
>
> ---------------------------------------------------------------------
> 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: -1 to Anakia [ or why the website is broken ]

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

are you guys talking about xml.apache.org? apache.org?

> 2. It needs to have an XML input format - we must eat our own dogfood.

this is a given, right?

> 3. It needs to be straightforward to learn and operate -  any committer
can
> update the documentation or regenerate the website.

I don't think you want that, you want the ability to push a particular page
or folder (including subfolders) live from the QA server -- maybe. This
should actually be part of the workflow:
- writer checks a box on some gui to give their ok it should be promoted to
qa (whoever that is, but there should be someone...)
 - qa checks a box (part of their qa system?--extra work) which indicates it
is ready to go live (or perhaps this pushes it live?).
- Meta-info, including workflow staus, information about the folders, pages,
general site structure and some layout info is all held in a DB or  in a
simple XML file under WEB-INF/xml/.
---- This is updated through a gui or direct editing/validating of the XML
document by the person making the content.
- Then daily, weekly this "config" file is read and the site is generated
with xalan's redirect extension and XSL.

> 4. It needs to be accessible to non-programmers - so that technical writer
> type folks can
> contribute to documentation.

The content needs to be TOTALLY separate from the presentation -- don't use
cocoon.  Content should be kept pure. The system should act on the content.
The content should just do what it is told, it should not do the telling.
This would need to be another workflow issue if content was submitted from
non-technical people who did not know anything about cocoon. And what about
the next guy? Will they have to do a transformation to clean up the XML?
Why?

Given pure content, the writer just needs to produce a simple docbook xml
document (don't tell me this is hard, especially with GUI editors that are
out now - in fact I have made/making a wysiwig tool... :).
Generally:
- some users can create folders
- some have the ability to upload a plain text *.xml document or edit
through web-front-end
---- true content - that is, the pure transferrable, resuable content
---- floater content - that is, content that could float anywhere on the
page (according to the XSLT) and most likely would appear on more than one
page (e.g. "Check out Xalan3 beta! - blah blah blah")
- they can create  or assign xml to a particular page(s) (there are ways to
make this painless to the user)

voila, you have a page at next scheduled generation or perhaps there is a
trigger that allows a FEW (1?) people the ability to push content live
outside of the regular schedule (daily, weekly, whatever)

> As far as I know no one is working on fixing the site layout.  I think
that
> perhaps we ought to have a
> contest for the site design.

that would be fun!



---------------------------------------------------------------------
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