xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Clark <a...@cyberneko.net>
Subject Re: [VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects
Date Thu, 06 May 2004 18:07:30 GMT
Neil Graham wrote:
>>> The idea of subprojects being simultaneously projects with their
>>> own subprojects looks like a terminal terminological disaster to
>>> me.  :)
>> That's because you keep referring to Xerces-J as a sub-project.
> That's because that's what it would technically be if something just
> called "Xerces" were a TLP (top-level project).

That's where we disagree, I guess. I consider all the parser
implementations as "Xerces", the TLP. They are built, packaged,
and shipped separately but I still consider them all the same
thing at that level. With that view, Xerces-* are all "Xerces".
Then the sub-projects are collective units below that (e.g.
HTML). Does that make more sense?

It certainly is more complicated because we have implementations
in different languages. I'm not disagreeing with that. But I
don't want the organization to be based on programming language;
I'd rather it be based on function. For example, XML parsing is
the TLP and things like HTML parsing is built from and is a
sub-project of that.

>> Perhaps it would be easier to start by defining what we want to
>> ship and then work backwards from there.
> Sounds good.  So far, we only ship archives containing jars, DLL's
> and source code that directly relate to XML parsing with standard
> interfaces. What additionally would you like to be able to throw into
> the mix?

Each parser implementation ships a binary and source package.
Just looking at Xerces-J as an example, people have always
complained about the size of the download. So we could break
down the way the parser is packaged and consider the things
that we "break out" as sub-projects.

Currently, the Xerces-J release contains the following:

   * parser (XNI, scanner, configurations)
   * validation (DTD, XML Schema, datatype library)
   * standard APIs (DOM, SAX)
   * HTML (DOM)
   * WML (DOM)
   * serializers
   * utility classes

Did I miss anything?

I'm not suggesting that each one of these be made a separate
package -- I just want a complete list to start talking about
what the current package contains.

The things I see in the future include things like:

   * HTML (scanner, configuration)
   * validation (RelaxNG)
   * additional APIs (pull-parsing)
   * data-binding

 From these lists I think we can decide what pieces are part
of the TLP and what pieces are not. The things that are not
part of the TLP are candidates for being made part of a sub-
project. For example, HTML is a good candidate: it would
include the HTML DOM implementation as well as an HTML parser
built on the Xerces framework.

Andy Clark * andyc@apache.org

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

View raw message