I'm writing to this list to ask for the creation of a new module in commons
scratchpad called "morphos".
The scope is to make a simple to use package for file format
transformations.
Currently we will concentrate on XML.
Committers needing access would be:
[EMAIL PROTECTED] (POI,Cocoon,Forrest)
[EMAIL PROTECTED] (POI)
[EMAIL PROTECTED] (POI)
[EMAIL PROTECTED] (Cocoon)
[EMAIL PROTECTED] (Commons et all)
Here is a draft proposal of what we intend to do.
---------------------------------------------
MORPHOS DRAFT PROPOSAL
---------------------------------------------
This is a proposal on what can be done with the Cocoon POI XML classes, and
expand the poject to have a highly focused but more wide-encompassing scope.
Here are the needs.
-------------------
Low overhead [ POI Dev Community ]
-------------------
The XML POI code has already had an impact on the work on POI, Cocoon and
Lucene and will undoubtably pull some impact on POI but this seems to me to
be the lowest. POI needs to remain tightly focused in thismoment to thrive.
-------------------
high visibility [ POI Dev Community , users ]
-------------------
High visibility on the xml part will undoubtly increase visibility of the
POI project.
-------------------
minimal hassle [ users ]
-------------------
Minimal hassle for configuring POI in other projects, as Cocoon.If its a
pain to install and configure, I won't use it, let alone anyone else.
-------------------
growth opportunity [ developers ]
-------------------
We need to make a community round it, and it should be easy to get in, and
interesting enough to get to know about it.
-------------------
generic xml<->file [ users, other projects ]
-------------------
The main concern is transformations of binary formats to/from XML (i.e.
generators and serializers), but could also include XML to XML (i.e.
transformers).
This could be a great bonus for users the now are limited to JAXP stuff, and
for projects like Cocoon that wouldn't need to keep so many other projects
inside just for this step.
---------------------------------------------------------------
PROPOSAL: MORPHOS
---------------------------------------------------------------
For this I propose the creation of a project called Morphos with the
scope of transforming file formats.
These code units to transform from-to binary-xml format
would be called XMorphers.
The activities related to this main concern include :
- developing and hosting code, preferably based on standard SAX/DOM
interface. Some Avalon/Cocoon-aware components can also be accepted : this
will promote Avalon & Cocoon as the framework of choice, but we must be
careful about avoiding dependencies where it is possible so that XMorphers
can be used in other environments.
- developing and promoting general-purpose frameworks for writing XMorphers.
This includes the ElementProcessor stuff, but also some other tools like the
Chaperon parser.
- manage a directory of available XMorphers, be they hosted by Morphos or
not (something like a dedicated equivalent to www.xmlsoftware.com)
- manage a directory of XMorpher-aware frameworks, i.e. tools where one can
plug XMorphers. We should provide here a compatibility matrix. Not to say
that Cocoon _must_ be the most compatible of all frameworks ;)
--------------------------------
ROADMAP - Approved
--------------------------------
Reviewed by:
[X]Scott
[X]Nicola Ken
[X]Sylvain
[X]Marc (lazy vote)
[X]Andy
This roadmap has been approved.
Project: Morphos (akin to xerces, xalan, ...)
1. [Nicola KEn] Create a commons-sandbox repository named
morphos
Committers will be: Andy, Marc, Sylvain, Scott and I.
2. [Nicola Ken] Install there the project template using
Centipede (http://www.krysalis.org/)
3. [Andy] Copy ElementProcessor in morphos, refactoring
the code in package
org.apache.commons.[todecide].components.elementprocessor
This is the generic elementprocessor framework without any POI
dependency.
4. [Nicola Ken] Add morphos to Gump.
5. [Sylvain&Scott All] Propose and discuss briefly about
the XM (XMorph)
interfaces that will be our contract as a project. Basically an
extension to the JAXP ones. Remember Avalon's role in all this.
6. [Marc&Andy] Once the XMorph interfaces are there, move the poi
elementprocessor implementation in morphos and
implement the XMorph interfaces for it.
In the future it is auspicable that the originating projects host
implementations if it suits them, but for now we need the
meat here.
POI can move them to morphos for a bootstrap, and
take control back after the 2.0 release, or when POI
is ready/has time for it.
7. [All] Decide the packaging of each XMorph Component, and the
"installation", so that the XM manager becomes aware of their
presence automagically.
Check that it works well with Cocoon too, and without
compulsory static config. Use Avalon.
8. [Sylvain] Remove elementprocessor from Cocoon and use
morphos jar instead; rewrite the Serializer to use XMorph
stuff.
In this way Cocoon can Serialize anything that XMorph has to give,
by just specifying the XMorph to use as a parameter to the
XMorphGenerator, XMorphTransformer, XMorphSerializer.
Keep stupid people like Andy in mind ;-P
9. [Sylvain&Nicola Ken et all] Do the XMorph move for other
projects Cocoon uses.
Examples are FOP & Batik.
10. [All] Drink (virtual) Champagne and beer once all this is done ;)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
