[CREATE] OpenRaster fallbacks (proposal/RFC)

[Martin Renold]

Here are some additional points/thoughts that might need discussion.

Forward compatibility:

OpenRaster[1] is about file exchange between applications with different
release cycles and implementation status.  When the specification is updated
in such a way that existing programs require changes to load new files
properly, OpenRaster has failed.

The addition of fallbacks (as they are discussed now) is such a change. 
Existing applications will silently drop elements with fallbacks, making the
file format look just as bad as any application specific format, as soon as
the first implementation that uses fallbacks hits the end users.

I hope we can "finalize" the minimum OpenRaster loader requirements now in
such a way that future versions of the standard will always allow
applications to save forward-compatible OpenRaster files (when required).

Below are some features that are expected to be saved into OpenRaster
documents in the future, and how they could be added.

New pixel formats:

As it is now, we need to use different attributes to save the "legacy" and
the new file format side-by-side in a compatible way.  For example:

<layer src="data/layer001.png" src_16bit="data/layer001_16bit.png"/>   
and also for fallbacks:
<cache src="caches/checkerboard.png" src_float='caches/checkerboard.dat'/>

Essentially, the specification needs to be updated to state that src=... 
attributes can only point to 8bpc PNG images, and all other formats need
other attributes. Ugly? Acceptable? Alternatives?

Fallbacks/Caches:

Two OpenRaster loaders should probably be supported: the OpenRaster
importer, and the native OpenRaster application that keeps XML in memory. 

The native application uses all caches and allows the user to navigate and
selectively edit the stack.  The importer (a simpler implementation) most
likely will want to drop/ignore/bypass all unknown effects and just load the
original pixel data of each layer (or <render> fallbacks for text etc.). 
Using the <effect> fallbacks might be a selectable option to get the image
look the same, but that could reduce the imported image to a single layer.

Either way, a finite number of tag elements with well known meaning would be
a requirement, as far as I see.  Also having well-defined locations where
the layer <stack> can continue inside of effects (if it can do that at all).

Layer modes:

Would a compositing mode other than OVER be implemented as an <effect> in
OpenRaster?  Or would the mode be part of the <layer> tag, which then can
also have a fallback?  If so, can a <stack> tag also have a compositing
mode?

Filter/Renderer variants:

Implementation might like to have a way to decide whether they can render
something without fallback.  This can be solved with version=... 
attributes.



[1] I realize there is also the goal to use OpenRaster as a tool to build
    application specific raster file formats.  When I say "OpenRaster" I
    really mean "OpenRaster / Long-term Archiving" or "OpenRaster Core" or
    however you want to call the file format that aims to be loadable by
    many applications.

bye,
Martin