Let's try to push a little bit further

Dear,

We agreed yesterday on the fact that the subordinated element have
much pro than cons

Let's take the proposal with
p:pipe and p:document (for external and here) and expand on that.

== Pro & cons ==
Pro :
-> No co-constraints. One model per element which could easily be done
by whatever schema languages (DTD, XSD, RNG, etc.) and which will help
auto-assisting in authoring tools.
-> Allow us to document the input element properly with a nested
p:documentation element (TBD)
-> separate clearly the use (input/name and the name) from where it
comes from and show more clearly the similarity with pipes.
-> Allow to aggregate directly into the input element from different source


Cons :
-> a little bit more verbose and may be esthetically unusual (strange?)
open question : ? will the defaulting story resolve this issue?

== Extension for pros ==
I propose some extension for pros

0/ Greater extensibility possibilities for V.next

1/ We could later imagine to write directly a simple-step into the
p:input/p:parameter/p:output element. I don't go into detail now, but
it's interesting for future releases.

2/ We can add fallback as proposed by Murray. I will just add that the
very very interesting fallback for me is from external to
external-or-here and should be written
<p:input name="in">
  <p:document href="external-local-conf-file">
    <p:document href="external-global-conf-file">
      <p:document><!-- with a duplicate p:document element -->
         ...here conf...
      </p:document>
    </p:document>
  </p:document>
</p:input>

I don't find easily use cases for the other kinds of fallback

== what is still missing for completeness now ==

1/ A clear story for defaulting (still in the kitchen...)

2/ A clear story for context input in for-each/viewport/choose/when
For this, I propose p:context without name as first child for those
elements. Furthermore it would remove the extra schematron in the RNC.
A careful reading shows that it raises an issue with the p:output with
fixed name "result" in case of p:viewport. In that case, we should add
another element, which could be p:expose with the same content as
p:output.

3/ A clear story for the role of select in p:input/p:parameter which
was proposed.
Now it seems clear that @select has to be on p:document and p:pipe for
grabbing just the interesting part of the stream. For clarity, i
propose to call it @filter

But it doesn't have to be confused with @test in p:when and
@select/@match in for-each/viewport

The former acts on the streams to filter this one
The latter is a parameter of the component

The shape is that @filter could be seen as a step directly into the
p:input/p:parameter element that filters on XPath 1.0.
It then could be extended with a real step that filter on XPath 2.0 for example

May be the alternate could be to propose a p:filter element with a
@select attribute and to allow it as a direct child of
p:input/p:parameter and to remove the possibility to put a @filter
attribute. In the filtered case it would give two levels of children,
but would it be so frequent ?
In that case, future extension to XPath 2.0 will be with a parameter
@version on p:filter which would be defaulted to "1.0" for XProc 1.0


Mohamed
-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Friday, 22 December 2006 17:05:41 UTC