[CREATE] OpenRaster and filters

[Kai-Uwe Behrmann]

Am 13.06.08, 12:08 +0100 schrieb Øyvind Kolås:
> On Thu, Jun 12, 2008 at 11:32 PM, Liam R E Quin <liam at holoweb.net> wrote:
> > On Wed, 2008-06-11 at 21:20 +0200, Cyrille Berger wrote:
> > [...]
> >> 1) <filter name="standard:blur" type="standard:gaussianblur">
> >>    <params>
> >>      <param name="radius">10</param>
> >>    </params>
> >>  </filter>
> >>
> >> 2) <filter:standard:blur radius="10" />
> >>
> >> 3) <filter:standard:blur>
> >>   <radius>10</radius>
> >>  </filter:standard:blur>
> >>
> >> The main weakness of 1) is that this doesn't allow DTD/RelaxNG checking and
> >> validation, but it makes easier to extend since you don't have to write the
> >> schema for your filter
> 
> > Yes, although with W3C XML Schema 1.1 you'd be able to do some checking
> > here, it would not be in a very modular way, I think.
> 
> How are we supposed to deal with third party filters that are not
> installed when parsing/validating? Personally I would prefer if the
> specification itself was a fixed rather rigid structure that allowed
> for expansion within that structure instead of expanding the
> tag/attribute vocabulary available.
> 
> > A compromise between (2) and (3) is to allow both
> > attributes and elements,
> > <blur radius="10" />
> > being the same as
> > <blur><radius>10</radius></blur>
> >
> > This is more complex to implement, and if the complexity isn't
> > worth while, I'd go for elements, i.e. (1) or (3).
> 
> GEGL currently supports boths, though the parser used currently isn't
> validating. The main reason for supporting the following syntax:
> 
> <filter type='standard:gaussian-blur'  std-dev-x='4.5' std-dev-y='2.5' />
> 
> as well as:
> 
> <filter type='standard:gaussian-blur'>
>   <params>
>     <param name="std-dev-x">4.5</param>
>     <param name="std-dev-y">2.5</param>
>   </params>
> </filter>
> 
> is that it scales further to animation based formats like used in
> http://pippin.gimp.org/oxide/ which is one of my earlier but larger in
> scope XML based formats like this.
> 
>  <filter type=''gegl:opacity'>
>    <params>
>     <param name='level'>
>        <value time='0.0'>1.0</value>
>        <value time='125.0'>1.0</value>
>        <value time='250.0'>0.0</value>
>     </param>
>   </params>
> </filter>
> 
> > You then have to ask what sort of validation you want; both
> > can have validation applied at some level.  Supplying a schema
> > of some sort that says that a particular set of parameters are
> > needed might be useful, although in general it can get
> > arbitrarily complex...
> 
> I do not see the added value this provides, for unknown uninstalled
> third party filters validation will not succeed, but it should still
> be possible to
> parse most of the structure and use it.

Validation of variables is very useful to find out a matching filter.
As the image description (OpenRaster) and the filter are different things, 
I'd say this makes sense. I am assuming here concurrenting filter sets, 
which can easily occure. The core of OpenRaster could specify a set of 
core filters. If this is easier to validate in attributes syntax, why not?
If for extensions, compared to the OpenRaster core, the elements approach 
seems more easy, so take this?

After all it might appear like a feature, to check for strict or
lazy following the OpenRaster specification.

> In general I'm in favour of 1), in GEGLs parsing code we permit a
> variation of 2) that uses non-namespaced attributes directly inside
> the filter tag, this mostly because it is a human writable short hand,
> the serialization code avoids it though.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org