On Tue, May 27, 2008 at 9:09 AM, Ferran Basora wrote:

Hello,

I have been watching the code about reading and generation of XML in GEGL. I think it is obsolete and pour extensible.

This code should not be extended much, if at all, it should perhaps be cleaned up, but that also pends on reaching agreement/consensus on the OpenRaster specification at freedesktop. Right now the current code serves the purpose and it is not meant to be extended much even when reshaped to be more inline with the OpenRaster plans.

One of the things that is pending with regard to the XML format is finding a way to make the meta operations be described as XML instead of C, this should also be easily doable continuing to use gmarkup (this might be unrelated to OpenRaster, or might be something that could be folded into the set of things specified there.)

I would like to see a significant advantage over the current parsing approach for dragging in an external library. For the serialization (generation of XML) I doubt that other approaches would yield any siginificantly saner code. It might even be better to completely remove all XML based functionality than to add a new dependency on an external library.

/Øyvind K.

On Tue, May 27, 2008 at 11:52 AM, Ferran Basora wrote:

On Tue, May 27, 2008 at 11:56 AM, Øyvind Kolås wrote:

On Tue, May 27, 2008 at 9:09 AM, Ferran Basora wrote:

Hello,

I have been watching the code about reading and generation of XML in GEGL. I
think it is obsolete and pour extensible.

This code should not be extended much, if at all, it should perhaps be cleaned up, but that also pends on reaching agreement/consensus on the OpenRaster specification at freedesktop. Right now the current code serves the purpose and it is not meant to be extended much even when reshaped to be more inline with the OpenRaster plans.

We may not have to extend the code but clean.

This cleaning could just as well take place without adding a huge external dependency, after all serialization to an XML format as well as loading it is quite far outside the core functionality of GEGL and might be suited for frameworks, libraries or applications on top.

As you say we have to wait for a final specification of OpenRaster format, but is propable that OpenRaster format will be a structure in XML, as OpenDocument. For this reason GEGL will need an interface to load OpenRaster format from an XML. I do not see feasible to remove completely all the XML functionality.

It shold be possible to implement all of the XML funcitonality using the other API and thus make the XML handling be an external library, perhaps called gegl-openraster or similar, for such a library a dependency on an external XML handling framework makes more sense. For internal XML need for GEGL (meta operations for instance), GMarkup which is currently used is sufficient.

Waiting for a final specification of OpenRaster doesn't make sense, we need to prototype things and check out how much of what has been created would be possible to push into OpenRaster, open raster is in part specified due to how the XML handling is done/being planned to potentially be done in GEGL.

GEGL never has promised to handle OpenRaster in any way, and the API documentation warns that the current XML is a stopgap measure that might be radically changed. OpenRaster is probably too domain specific since it might be difficult to push for instance the more video editing and compositing like things people would want to do with GEGL (ref http://pippin.gimp.org/oxide/) which is a precursor/inspiration for OpenRaster, that extends the scope to animations and sequences of clips.

Going down a route of making the OpenRaster/tree based XML less prominent in GEGL is probably sane since the pure internal representation of GEGL does not use trees. A more free form XML for describing the graph for use with the meta operation as well might replace all of the existing XML.

/Øyvind K.