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 * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
