Re: [ACTION-155] (related to [ISSUE-16]) parameters for rules

2012/7/6 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix, all,
>
> > ...So in addition to the technical issues, we need to
> > think about whether global implementations of ITS 2.0
> > will support this, for each data category they implement.
> > ...
> > I would be reluctant to complicate this by saying
> > "some processor MAY implement parameters, other not".
> >
> > Any thoughts?
>
> Just a couple of notes:
>
> - We don't have restrictions about not using variables in XPath
> expressions, but we don't have a way to declare them and provide defaults.


Well, implementations have their own ways to do that, e.g. saxon for XSLT
with command line parameters.


> So I think it's important to have <its:param> (isn't it like fixing a 1.0
> oversight?)
>

You can see this also as introducing a feature that is not supported by
each XPath implementation natively. It may be no burden, but if we do that
we'll need test cases too, and each implementation that implements global
rules needs to pass them.

So would implementors be willing to assure that they pass the test cases?
If yes, let's go ahead.


>
> - Should we make a distinction between:
>
> A) supporting <its:param>, that it: understanding <its:param> and
> providing the defaults value to the XPath engine,
>
> and B) (in addition) supporting overriding the ITS parameters, that is:
> providing a way (tool-specific) to set values other than the defaults?
>
> I don't think it's very useful to support A without offering B. But from a
> conformance viewpoint maybe only A is required?


Yes, I think that would be enough I think.

Felix


> I'm thinking that some tools may have issues implementing B. For example
> tools that currently rely on just processing the XML and the ITS rules (and
> have no way to set any addition options: no UI or no command-line options).
> But I'm probably just over-complicating things, and we don't need to make a
> distinction.
>
> -ys
>
>
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow