Re: XProc Agenda 22 Feb 2007

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.

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

|       3. Pre-defined vs. arbitrary application parameters
|          (<p:initial-mode>foo</p:initial-mode> vs. <p:parameter
|          name="initial-mode" value="foo"/>)

The status quo on this question is that components have p:input,
p:output, p:import-parameter, and p:parameter elements.

The difficulty, I think, is that some components have parameters that
are specific to the component (like "initial-mode" for XSLT2,
"phase" for Schematron, or an initial value of processContents for
W3C XML Schema) and some (like XSLT) accept arbitrary parameters.

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 use the existing parameter mechanism, we could say that the
parameter named p:initial mode is either passed to the application
as a "arbitrary parameter" or it isn't. Either way, the practical
impact seems pretty small.

The downside is that the initial mode is quite a different sort of
thing from an arbitrary parameter like "chunk-filename-extension".
Using the same mechanism for both is at least potentially confusing.
We also (probably) don't get any error checking: <p:parameter
name="p:starting-mode"> would (probably) simply be an arbitrary
parameter not a misspelling of 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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.