W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Re: XProc Agenda 22 Feb 2007

From: Alex Milowski <alex@milowski.org>
Date: Thu, 22 Feb 2007 07:38:45 -0800
Message-ID: <28d56ece0702220738k3369ae8u6062146afa6248cd@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org
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
can't be made when the pipeline is authored.  I don't have an example of
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.


> 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

Bertrand Russell in a footnote of Principles of Mathematics
Received on Thursday, 22 February 2007 15:38:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC