- From: Innovimax SARL <innovimax@gmail.com>
- Date: Fri, 22 Dec 2006 18:05:27 +0100
- To: "XProc WG" <public-xml-processing-model-wg@w3.org>
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