Hi Andy,
> 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.
Conceptually, the only difficulty I'd have with this is that it's no longer
crystal clear what the commonality between the subprojects is. I'd thought
that the "Xerces" TLP would be all about Apache's offerings related
specifically to XML parsing first, and perhaps very closely related
technologies second. Putting the related technologies on the same level as
the XML parsing services seems like an interesting way of recasting what
the XML project tried to do in the first place.
> 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.
I'd been guessing that. :)
> And it's my assumption that it would
> be grouped together with the HTML DOM implementation.
Seems fair.
>> 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.
But the trouble with the current Xerces-J isn't that it's a big grab bag,
it's that it's a big lump! If it were a grab bag of jars with separated
functionalities, I think we'd find most folks wouldn't have all that much
trouble figuring out what they actually wanted--heck, most folks even seem
to be grasping the "endorsed standards" complexities that arose with JDK
1.4.
So I'll stick by my idea of an organization that looks like this:
* project: the top level project (TLP), charged with XML parsing
and closely allied technologies
* sub-project: either
o an XML parser implementation in a particular language, or
o a "tools" subproject containing useful products that are
tightly bound, usually by nonstandard API's, to one of the other
subprojects
The tools subproject could contain products from as many languages as there
were parsers. I'm also fine with removing the restriction that we have one
parser per language; we may want a Xerces-J-Pull at some point.
Once again, I'd love to call on other folks from Xerces-land. Andy and I
are having a good time talking among ourselves, but it's tough to gauge the
consensus of a community when you only ever hear two voices...
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Andy Clark
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
et> cc: [EMAIL PROTECTED], [EMAIL
PROTECTED],
[EMAIL PROTECTED]
05/10/2004 07:04 Subject: Re: [VOTE]: motion to
transform Xerces into a top-level project as a member
PM of the "federation" of XML projects
Please respond to
pmc
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 * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
