xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: [DISC] Proposal: new xml-core project for standards-based files
Date Fri, 13 Apr 2001 21:03:53 GMT

I'm writing up my [VOTE] proposal now, so I'll be soliciting your votes in
a day or two; I wanted to comment on a couple of issues first.

---- you Martin Stricker <shugal@gmx.de> wrote ----
> Shane_Curcuru@lotus.com wrote at Fri, 30 Mar 2001 16:21:40 -0500:
> > I propose a new xml.apache.org subproject to fulfill the need for a
> > central repository for various XML standards-based files.  Comments on
> > this specific proposal please, everyone! (not like I really have to
> > ask... 8-)
>
> This sounds like a Really Good Idea! If I understand this correctly you
> want two things: 1) A central repository for external code which is not
> altered by xml.apache.org. 2) A central repository for code which is
> used in more than one xml.apache.org project and is coded at
> xml.apache.org.

Actually, what I sort-of want is 3) to form is a targeted community where
we can hash out the best way to manage your points 1) and 2) above.  It's
clear from discussion that we all like the basic idea and at least much of
point 1), so I'd like to go form the subproject now (and hence the
community of people who care about / want to contribute to this effort) and
then within that community try to get more focused on making this stuff
work.  (With plenty of feedback from the whole xml.apache.org community of
course!) -sc


> We certainly should include other
> languages than Java. For Perl there are some modules in CPAN
> http://www.cpan.org/ which might be useful.

Yup, /c /java /perl will be separate directories.  I'm more of a Java-head
so I'll leave the building of the perl side to someone else for now; we
also need to note licensing issues when checking in other organization's
code.


> Of course you have to be cautious
> about the interfaces: Never change a Common interface but add a new one
> if necessary and maybe deprecate the old (and delete it if you have
> assured no one is still using it).

Yup, we'll have to ensure this subproject's guidelines make updating
versions and removing/changing existing API's very well documented so that
other xml projects won't get surprised.  The people who I imagine will
really make this subproject work are the kind who will be thinking about
this from the outset... -sc

- Shane


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