Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
Message-ID: <007801c10c7a$7fbb2880$6601a8c0@chubby>
From: "Robert Koberg" <rob@koberg.com>
To: <general@xml.apache.org>
References: <OF3D959322.3B9E1A29-ON85256A88.00721F52@raleigh.ibm.com>
 <007901c10c2d$23978a00$0a00a8c0@boo> <004e01c10c74$65efab70$6601a8c0@chubby>
Subject: Re: -1 to Anakia [ or why the website is broken ]
Date: Sat, 14 Jul 2001 08:34:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <rob@koberg.com>
To: <general@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