[CREATE] OpenRaster and filters

[Ø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.

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.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
 -- William Gibson
http://pippin.gimp.org/ http://ffii.org/