xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Forrest Layout 1.4
Date Thu, 03 Jan 2002 00:44:28 GMT
Edwin Goei wrote:
> 
> Stefano Mazzocchi wrote:
> >
> > Sam Ruby wrote:
> > >
> >
> > > It seems odd for a subcategory of xml.apache.org to be "xml".
> >
> > Yeah, I know, but couldn't find a better term.
> >
> > > I'd suggest parallel forms of verbs:
> >
> > > "parse"
> >
> > if we do this, this category will remain locked to Xerces/Crimson
> > (hopefully crimson will disappear one day since we don't need two
> > parsers).
> >
> > I like the concept of using actions to discriminate categories, but I'd
> > love to have something wider than 'parsing', but 'handle' is way too
> > general.
> 
> Why would you want a wider category than parsing?  It seems to me that
> an XML parser is the most basic piece of software a developer would
> understand and would be a natural division.

I was trying to make xml-security fit without making a category for
'parsers' and 'security'.

> Also, regarding your crimson comment.  There are current and probably
> future developers that are/will be using crimson and I think it should
> be available for download somewhere on the apache site.  The web pages
> for crimson already say that future development will focus on the
> Xerces2 parser.

We need to decide what we do with the '2.0' releases.

Currently we have:

 1) Cocoon 1 and 2
 2) Xerces 1 and 2
 3) Xalan 1 and 2

and users use both, so we must keep supporting both.

having a URI space like

 http://xml.apache.org/cocoon2/

is like shooting ourselves in the foot: what happens when 3.0 is out?
another load of broken links?

We decided to avoid that and moved everything to /cocoon, but people
complained because the old Cocoon documentation was gone.

Hopefully, we'll never do such major transition and proceed
incrementally in the future, but we must be coherent from the start or
broken links will plague us in the future.

[we can't avoid to generate some broken link, but we should try to
minimize them]
 
> Perhaps another idea would be to base the categories on communities.  I
> think for parsing, there is a single community (split into languages)
> and most issues are discussed on xerces-j-dev or xerces-c-dev or for
> crimson, general@xml.  There is also a single XSLT community at
> xalan-dev, which has more than one java transform engine.  I am less
> sure about other projects.  This would make it easier to point to the
> appropriate mailing list.

I received comments from people that wanted a list of sofware in
alphabetical order. Sam wants functionality grouping. You want community
grouping. Others might want importance grouping and somebody else
userbase size grouping.

One size can't fit all, expecially in a mess like an apache project.

I think we should make it easier for the newbie user and use that as a
meter: in this case, functionality grouping makes best sense to me on
the software list.

But you're right, at the same time, we must provide a way to understand
what community maps to what lists and what software. This will be the
role of some other page.

If you look in Forrect 1.5 home page you'll find 5 tabs:

 1) home (the current page)
 2) what we do -> project mission and detailed description
 3) how we do it -> project rules, charter, legal stuff, project
management
 4) who we are -> list of people with short bio, picture, apache status
and so on, list of communties and how they are related to the various
subprojects/efforts
 5) how to join -> subscription information, community guidelines,
netiquette, glossary of terms, informative links, info for getting
developers started, who to contact for apache sysadmin stuff, FAQ for
partecipating in the communities.

the home links to every (sub-project|language) couple, quick links to
the project-wide mail lists subscription and quick links to forrest and
gump (and all other eventually future site-wide admin/dev tools)

Maybe the 5th tab (how to join) should be split into:

 a) how to join -> subscription information, community guidelines,
netiquette, glossary of terms, informative links
 b) how to work (a better tabname, anyone?) -> info for getting
developers started, who to contact for apache sysadmin stuff, FAQ for
partecipating in the communities, etc..

Am I missing anything?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@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


Mime
View raw message