Re: [VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects

Andy Clark <[email protected]> wrote on 05/12/2004 01:44:27 PM:

> Neil Graham wrote:
> >>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
> 
> It's not clear to *you*, is what you mean. It's perfectly clear
> to me. ;)
> 
> > that the "Xerces" TLP would be all about Apache's offerings related
> > specifically to XML parsing first, and perhaps very closely related
> > technologies second. 
> 
> That sounds exactly like what I'm proposing through my use of
> the terms "project" and "sub-project". Parsing is the project
> and things related to parsing are sub-projects. Products is
> the way that the implementations are separated from each other
> within the project.

Though I have my own opinions on what I believe projects and sub-projects 
should be, I'll refrain as I think we're getting far too caught up in 
terminology. In whatever charter we agree on, I feel it should contain 
language flexible enough that it would permit additional XML parsing 
technology and synergistic applications to be adopted by the Xerces TLP. 
When a proposal for something new to be added to Xerces comes a long, 
we're going to have to discuss whether it's a good fit anyway (and vote on 
it). If it is determined that Xerces would be a good home for a particular 
proposal, then if it is meant to stand on its own (as a sub-project or a 
product or whatever name makes you happy), it would go through the 
incubation process and join Xerces upon meeting the exit criteria of the 
Incubator. If it's a contribution which fits well in the existing efforts: 
Xerces-* (or future sub-projects, products, etc...) like support for 
another module of DOM or an new XML parsing API, then perhaps it could be 
incorporated directly into one or more of the Xerces-*.

> So someone comes to the website looking for XML parsers and
> they go the the Xerces Project. Then they decide what language
> they need, Java, so they download the Xerces-J product. Next,
> they want to be able to parse HTML, so they look at the Xerces
> HTML sub-project. There they see that there is an implementation
> in Java for use with the XML parser they just downloaded.
> 
> In this situation, of course there are things that need to be
> broken out of Xerces-J as it stands today. But once that is
> done, they are each developed and packaged separately. It's
> primarily the website organization that reflects the hierarchy
> and relationships between these separate things.

I assume you're referring to components such as HTML DOM and WML DOM. As 
far as I know this code has no maintainers. There's been at least one 
request [1] to deprecated and/or remove the HTML DOM implementation 
because it's appearently badly broken. Without people willing to take 
ownership, I'm not sure how spinning off these components on their own 
would improve this situation.

> >>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.  :)
> 
> I'm asked on a regular basis if/when it will be merged into
> Xerces-J so this is a perfect opportunity to do that.
> 
> >     * 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
> 
> But this puts dependent products at the same level as the
> parser. You would think they would be *under* the parser
> because of the dependency.

Because some code base has some dependency on another shouldn't 
necessarily mean they need to be organized that way. If this were the way 
things had to work, Xalan-C and Xerces-P would be under Xerces-C and 
perhaps Xerces-J would be under xml-commons because it depends on the XML 
APIs and the resolver.

> > 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.
> 
> Well, that was certainly one of my biggest problems with the
> original draft.
> 
> > 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...
> 
> It does seem rather quiet around here. I'm surprised that
> noone else has added their ideas to the discussion. Perhaps
> they're scared of me. ;)
>
> -- 
> Andy Clark * [email protected]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

[1] http://nagoya.apache.org/jira/browse/XERCESJ-890

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]