xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Graham <ne...@ca.ibm.com>
Subject Re: [VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects
Date Wed, 12 May 2004 03:47:20 GMT





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:  neilg@ca.ibm.com




                                                                                         
                                             
                      Andy Clark                                                         
                                             
                      <andy@cyberneko.n        To:       pmc@xml.apache.org           
                                                
                      et>                      cc:       general@xml.apache.org, xerces-c-dev@xml.apache.org,
                         
                                                xerces-j-dev@xml.apache.org              
                                             
                      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 * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: pmc-unsubscribe@xml.apache.org
For additional commands, e-mail: pmc-help@xml.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message