commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject [Morphos] Java data morphing package
Date Tue, 04 Jun 2002 20:18:50 GMT
*CROSSPOST * PROPOSAL OF PARTICIPATION *

Welcome to the first public discussion about project Morphos.

This message is being posted to many lists because it has the aim of solving
a common need.

The discussion will continue, for those interested, on the jakarta commons
mailing list.
To subscribe, send an empty mail to
commons-dev-subscribe@jakarta.apache.org


What is Morphos?
-----------------------------
Morphos will be a Java Api and implementation for transforming data, in any
form it may be: xml, streams, objects.

It focuses on the API and framework, and demands implementation to other
projects-modules wherever possible.


Why Morphos?
-----------------------------
Morphos starts from a need around a community of developers, with an initial
charter committed in Jakarta Commons Sandbox.
Before anything got committed, it has slightly evolved from being tied
initially to XML.
Here is the old charter
(http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/morphos/PROPOSAL.txt?
rev=HEAD&content-type=text/vnd.viewcvs-markup).

This mail illustrates the latest status of the private discussions, and a is
the start of the public one.

Currently there are many projects that need or would benefit from a generic
transformation API:

  - Jakarta POI -

      OLE<->XML transformations

  - Cocoon -

        using a single api and a contrib section for the
        loads of components it now hosts in the core

  - FOP -

        redesigning the main interface for FO<->PDF,MIF,...etc

   - Krysalis Wings -

         transforming chart XML format to SVG or image formats

Other projects that can be wrapped round this api are numerous:
  - Batik (image transcoders)
  - Xerces-Xalan
  - Avalon Excalibur Converter
  - Commons Digester
  - Jakarta-commons-sandbox Jelly
  -  etc...

A componentization of the transformation process can help reuse and minimize
code duplication.


What does it do?
-----------------------------
 Morphos should simply do:

 data  --> morphos ---> data

 Data can be:
   - stream
   - events
   - objects

I don't see other basic generic "data" types, since files and such can
become streams and viceversa without any format or form conversion.
I want a *very* simple api, with no duplicated methods.
IE having get(Stream) and get(File) is not necessary IMO, since they do the
same thing.
The main API must be very simple. We can always add helper classes.

 I took look at these APIs:
 - Jaxp
 - Batik Transcoder

Jaxp:
Baised towards xml (more in package names than in fact). Already has a bad
track on version using (the infamious "endorsed" dir and param). Uses static
method for getting the transformer.

Batik Transcoder:
Good API but it's source can contain a Reader, InputStream, Contenthandler,
etc, so it's tied to these.
No support for pipelining of transcodes.

Ok, but in Concrete?
------------------------------

Here is the proposed API, all in package org.apache.commons.morphos:

/**
 * The interface that is implemented by classes that morph.
 * It uses two params and not a return value to make it usable with
 * event based Objects (contenthandlers).
 * Parameters are key pairs, used to configure the Morpher.
 * Events in the Morpher are notified by registering a listener.
 */
public interface Morpher {

    void morph(Object input, Object output) throws MorphException.
IOException;

    void addParameter(String paramName, String paramValue);
    String getParameter(String paramName);
    void remove Parameter(String paramName);
    String[] getParameterNames();
    String[] getParameterValues();

    void addNotificationListener(NotificationListener nl);
    void removeNotificationListener(NotificationListener nl);
    void clearNotificationListeners();

}

/**
 * A Morpher made out of a sequence of morphers.
 */

public interface MorpherPipeline extends Morpher {

    void addStage(Morpher nextMorpher);

}



/**
 * The Factory for Morphers.
 * There is a getDefaultFactory method for easy use.
 * Used in frameworks it's better not to use it and rely on
 * services that give the proper MorpherFactory.
 */
public abstract MorpherFactory  {

    Morpher getMorpher(DataType inputType, DataType outputType);
    Morpher getMorpher(name);

    Morpher getPreparedMorpher(DataType inputType, DataType outputType);
    Morpher getPreparedMorpher(name);

    static MorpherFactory getDefaultFactory();
}


/**
 * Describes what the format of the data is.
 * It consists of a mimetype (format) and a dataForm (representation).
 * For example a gif image file and a jped image file have a different
mimetype but same dataform (file).
 * An SVG file and an SVG DOM in memory have same mimetype but different
dataform.
 */
public interface DataType {

    void setMimeType(String mimetype);
    void setDataForm(String format);

    String getMimeType();
    String getDataForm();

}


--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message