> > - The options schema uses a different modeling approach than all the others.
> > It's not that all the others are consistent but this one seems to be
> > introducing yet another way to model options, i.e. all as attributes of one
> > element. Maybe we should make it consistent with at least one of the other
> > option schemas.
> I took this one because it's very compact. So, how should it be done. With
> Jsoniq :-)? Or XML module style:
> <opt:options>
>    <opt:enable component="function" />
>    <opt:enable component="index" />
> </opt:options>
I would do it the way the schema-tools-options or archive schemas do it (e.g.
<opt:function>true</opt:function>). Alternatively, it could be done similar to 
serialization options (e.g. <opt:function value="true"/>).
Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to