Re: XProc Agenda 22 Feb 2007

On 2/22/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
>
> My thoughts, for the record.
>
> / Norman Walsh <Norman.Walsh@Sun.COM> was heard to say:
> |       1. Components that act as interfaces to multiple applications
> |          (p:validate for W3C XML Schema 1.0, W3C XML Schema 1.1, RELAX
> NG,
> |          and Schematron validation vs. multiple components.)
>
> I think the status quo on this question is that components *do not*
> act as interfaces to multiple applications. At least, our description
> of the XSLT component does not suggest that it can do 1.0 or 2.0
> transformations. We've described p:validate somewhat sloppily but we
> don't actually have such a component in the current draft.
>
> I would prefer not to allow components to act as interfaces to
> multiple applications. I'd prefer
>
>   p:xslt
>   p:xslt2
>   p:xquery
>   p:relaxng
>   p:xmlschema
>   p:schematron
>
> over p:transform and p:validate that do all of the above.


I agree that we don't want generate "validate" and "transform" components.

I had imagined having a generic "xslt" component that could choose
between XSLT 1.0 and 2.0 based on the version attribute.  I do that now
and it is useful.  In the end analysis, when I'm writing those pipelines
I could easily choose the component name.

As such, what we are excluding is some kind of dynamic pipeline where the
choice
can't be made when the pipeline is authored.  I don't have an example of
this
and so I'm OK with excluding this case.


|       2. Step names (<p:step type="p:xslt"> vs. <p:xslt>)
>
> The status quo on this question is <p:step type="p:xslt">. I think I'd
> prefer <p:xslt>. Our discussions last week demonstrated that our
> hesitation on the basis of validation was simply unwarranted.
>
> Using p:xslt would, I think, on balance, be easier for users to use
> and understand. It also opens up the possibility of having different
> content models for the different components.



Yes!



> There are a few ways that we could handle this.
>
> 1. We could omit this capability
> 2. We could use the existing parameter mechanism,
>    <p:parameter name="p:initial-mode">.
> 3. We could allow specific named parameters, <p:initial-mode>


...

If we allow specific named parameters, and we want it to be possible
> for them to be dynamically specified, we'll have to tackle the problem
> of how to assign values to them.
>
> Personally, I could live with them not being dynamic in V1.
>
> I have a slight preference, I think, for option 3 with static values.



I have a preference for (3) as well.

Keep in mind that *any* component developer can:

   * never use "specific named parameters"
   * allow "regular" parameters to override specific parameter values.

My use case for the jruby script component is that where
I want the script statically.  I'm not going accept the script
dynamically because of other considerations (e.g. security).



-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics