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

[Michael Glavassevich]

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]