commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: jakarta-commons-sandbox/morphos PROPOSAL.txt
Date Tue, 02 Apr 2002 06:55:24 GMT
nicolaken    02/04/01 22:55:24

  Added:       morphos  PROPOSAL.txt
  Initial Morphos proposal commit.
  Revision  Changes    Path
  1.1                  jakarta-commons-sandbox/morphos/PROPOSAL.txt
  Index: PROPOSAL.txt
  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
  Currently we will concentrate on XML.
  Committers needing access would be: (POI,Cocoon,Forrest) (POI) (POI) (Cocoon) (Commons et all)
  Here is a draft proposal of what we intend to do.
  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.
  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
  - 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]Nicola Ken
  [X]Marc  (lazy vote)
  This roadmap has been approved.
  Project: Morphos (akin to xerces, xalan, ...)
  1. [Nicola KEn] Create a  commons-sandbox repository named
          Committers will be: Andy, Marc, Sylvain, Scott and I.
  2. [Nicola Ken] Install there the project template using
        Centipede (
  3. [Andy] Copy ElementProcessor in morphos, refactoring
     the code in package
     This is the generic elementprocessor framework without any POI
  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
       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         
              - verba volant, scripta manent -
     (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message