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 Mon, 10 May 2004 23:04:30 GMT
Neil Graham wrote:
> [snip]

Categorizing Xerces is difficult because of the fact that we
have implementations in different languages that are parallel
in function but don't share design or implementation, as
you've stated. And there aren't many Apache projects that are
similar in that respect. So we need something very different
than most of the existing Apache TLPs.

How do you feel about settling on the following terms:

   * project:     the top level project (TLP)
   * sub-project: a functional category related to the TLP
   * product:     a specific implementation

So "Xerces" would be the project whereas "Xerces-J" would
be a product release of Xerces in Java. An example sub-project
would be "HTML" which, again, would have products based on the
implementation language. They would be bundled together for
organizational reasons, not for releases.

How does that structure strike you?

> I have trouble accepting the idea that the WML DOM implementation
> that got dumped on Xerces-J all those years ago has much to do with
> Xerces-P...

You're right, it doesn't. But WML "parsing & APIs" are
language independent concepts. It's just that we only have a
single implementation: Java.

> And so are XSLT processing and XML Security work...  I'm not
> necessarily opposed to bringing something like an HTML parser into
> the Xerces fold, but it does seem you could argue it both ways.

I'm specifically trying to organize the Xerces TLP so that
I can formally donate NekoHTML to the Xerces project for the
Xerces-J product. (Assuming the community wants it.) So I
want to make sure that there's a clear home for it within
the new TLP structure. And it's my assumption that it would
be grouped together with the HTML DOM implementation.

> them products of Xerces-J, subsubprojects of Xerces-J, or put them in
> a sandbox or Xerces-commons area composed of componentry closely

That's an interesting idea but I think it dilutes what's
offered and makes it more difficult for people to pull out
the specific tools they're looking for -- we'd just be moving
the big grab-bag down one level.

> allied to XML parsing, it's all good.  The only point I'll have to
> stick to is that there isn't some magical Xerces entity that contains
> all the components of Xerces-* that are considered "core" to parsing.

Agreed. The distribution would still be separated by the
implementation language, just as it is today.

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