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

XProc Minutes: 4/5 Nov 2010

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 08 Nov 2010 11:36:48 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2iq07ydpb.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2010/11/04-05-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 183, 04-05 Nov 2010


   See also: IRC logs, [3]04 Nov and [4]05 Nov.


           Norm, Vojtech, Alex, Florent, Mohamed, Carine, Henry (on the phone
           for item 11)

           Henry, Paul, Jeni




     * [5]Topics

         1. [6]Accept this agenda?
         2. [7]Accept minutes from the previous meeting?
         3. [8]Next meeting: telcon, 18 Nov 2010?
         4. [9]Review of proposed XProc errata
         5. [10]Allow p:xslt to produce an empty sequence?
         6. [11]xml:id processing in XProc
         7. [12]Shouldn't choose report err:XD0026 too?
         8. [13]New and upcoming XProc implementations
         9. [14]Simplified template step
        10. [15]Charter for XProc
        11. [16]XML processor profiles
        12. [17]Iteration
        13. [18]More future step possibilities
        14. [19]Investigating methods for making pipelines easier to build
        15. [20]"Streaming" XProc
        16. [21]More discussion of possible extension steps

     * [22]Summary of Action Items


  Accept this agenda?

   -> [23]http://www.w3.org/XML/XProc/2010/11/04-05-agenda

   Henry can call in between 16:15 and 17:00, so we'll move review of
   processor profiles to the end of the day


  Accept minutes from the previous meeting?



  Next meeting: telcon, 18 Nov 2010?

   No regrets heard.

  Review of proposed XProc errata

   -> [25]http://www.w3.org/XML/XProc/2010/05/wd-comments/

   (We've got things mixed together on the issues list; Norm will fix that

  Allow p:xslt to produce an empty sequence?

   Vojtech: It would require all implementations to change.

   Alex: It is annoying.

   More discussion...

   Norm: I don't hear consensus to make the change as an erratum.

   Mohamed: I think it's an uncommon problem, and the folks who encounter it,
   the ones using xsl:result-document, are probably able to work around it.
   ... It might be more confusing for users with simpler stylesheets to
   understand why it's a sequence.

   Proposal: No change to the spec, the test suite has already been updated
   by Vojtech.


  xml:id processing in XProc

   Mohamed: We only say "may" in the spec, so I don't think we can say that
   xml:id processing is mandatory.

   Vojtech: But the revised profiles document makes it explicit.

   Mohamed: We don't have xml:id in the implementation-defined features list.

   Norm: I think we need to do that as an erratum.
   ... I just don't think we can change "may" to "must" in an erratum.

   <scribe> ACTION: Norm to draft an erratum to add xml:id to the
   implementation-defined features list. [recorded in

   Alex: If you were going to make xml:id required, you'd have to say it was
   performed on all the inputs where ever they came from, on p:document, on
   p:inline, and on the outputs of all steps.
   ... Should we say that in the spec as part of the erratum, explaining why
   xml:id was left as "may"?

   Norm: Yes, I'll try to do that when I add the text to make xml:id

   Proposal: No technical changes, just clarify that xml:id is an
   implementation-defined feature


  Shouldn't choose report err:XD0026 too?


   Norm: this looks like a straight-up erratum to me

   Sounds of general agreement

   Proposal: Fix the prose for p:xpath-context to make it clear that
   err:XD0026 should be raised there too.


   <scribe> ACTION: Norm to propose an erratum to fix p:xpath-context
   [recorded in [28]http://www.w3.org/2010/11/04-xproc-minutes.html#action02]

  New and upcoming XProc implementations

   (Topic suggested by Mohamed)

   General discussion: Tubular submitted test suite results recently. There's
   a .NET implementation in the works from Oliver H. Vojtech knows of another
   Java implementation that's coming.

   Mohamed: We should update the public XProc page too.

   Norm: Yes. Want to take a stab at it?

   <scribe> ACTION: Mohamed to propose new text for the public XProc page.
   [recorded in [29]http://www.w3.org/2010/11/04-xproc-minutes.html#action03]

  Simplified template step

   Mohamed: You can do it with XSLT

   Some exploration of how XSLT Simplified Stylesheets work

   Much discussion...

   Alex: Are some of these things really just syntactic sugar that you could
   implement by translating to some equivalent 1.0 pipeline?

   The scribe provided the following summary of this issue after lunch:

   The WG discussed the problem of a "simplified template" step, something
   that would make it easier to construct documents with dynamically
   generated content.

   There seem to be two paths: a clean-slate design targetted at XProc V.next
   where we can change the semantics of pipelines in any way we want, or a
   design that would be valid in XProc 1.0. Although the former might produce
   the best results, for the short and medium term, it seemed wise to
   consider what we could accomplish within the constraints of XProc 1.0.

   After much discussion, the WG concluded that we could achieve significant
   simplification with two new XProc atomic steps: p:in-scope-names and

   <p:output port="result" primary="false"/>

   The p:in-scope-names step is roughly analagous to the p:parameters step.
   It creates a c:param-set document containing one c:param element for each
   in-scope variable and option. The order of the c:param elements is

   <p:input port="template"/>
   <p:input port="source" sequence="true" primary="true"/>
   <p:input port="parameters" kind="parameters"/>

   The p:document-template step makes a verbatim copy of its source input
   with one exception: within attribute values and element content, every
   expression delimited by curly braces is treated as an XPath expression and
   replaced by the result of evaluating that expression.

     * The context item used during evaluation of the expression is the
       document that appears on the context port. It is a dynamic error
       err:XDxxxx if more than one document appears on the context port.

       In an XPath 1.0 implementation, if p:empty is given or implied as the
       context, an empty document node is used as the context node. In an
       XPath 2.0 implementation, the context item is undefined. It is a
       dynamic error (err:XD0026) if the select expression makes reference to
       the context node, size, or position when the context item is

     * The names of all the parameters passed to the step are available as
       variable names during expression evaluation.
     * If an expression selects one or more nodes from the context, a copy of
       those nodes is inserted in the result document, unless the expression
       occurs in an attribute value in which case their string value is used.
     * The sequence "{{" is replaced by a single, literal "{".
     * The sequence "}}" is replaced by a single, literal "}".
     * The version of XPath supported by the step is implementation-defined.
       The XPath context is the step XPath context; this means, for example,
       that the XProc extension functions cannot be called.

   Suppose you wish to construct the following document:

   <c:request method="POST" href="http://example.com/post"
              username="user" password="password">

   Where the method, href, username, and password are computed by the
   pipeline as either options or variables and the body of the post is
   selected from one of the pipeline's input documents (say

   Using only XProc 1.0 standard steps, this can be accomplished with several
   successive p:add-attribute steps and a p:insert step. (There may be other
   ways as well, though they are all a bit tedious.)

   Using these new steps, it's much simpler:

   <p:in-scope-names name="vars"/>

     <p:input port="template">
         <c:request method="{$method}" href="{$uri}"
                    username="{$user}" password="{$password}">
             { /h:html/h:body/h:div[3] }
     <p:input port="source" sequence="true">
       <p:pipe step="main" port="result"/>
     <p:input port="parameters">
       <p:pipe step="vars" port="result"/>

   This is in many ways like a simplified stylesheet in XSLT. In fact, aside
   from the new semantics associated with curly-braces in element content, it
   could be implemented in XSLT. Conversely, it could be implemented in
   XQuery, if you were willing or able to escape all of the markup and pass
   it to the p:xquery step in a c:query element.

   (There was some subsequent editing of the examples and fine tuning of
   semantics, but the WG agreed to publish something along these lines as a
   WG Note. Norm agreed to write it up.)

  Charter for XProc

   Norm: What should we do next? Fold up our tents and go home or do more

   Liam: The XML Activity has a charter, as do the individual working groups.
   They all expire in January. This is normal, it's a chance for the
   membership to review activities.

   Liam outlines the process.

   Some discussion of 1 or 2 year charters; a 2 year charter implying XProc
   2.0 work.

   Norm: We have two implementations and reports of as many as four or five
   more in the works.
   ... I think I'd like a 1 year charter for maintenance and possible
   requirements gathering, then after a year see where we are.

   Liam: I'd like to be able to consider pipelines, with synchronization
   points, as a possible solution for more complex processing requirements
   ... For example, as an alternative to XQuery Scripting Extensions.

   Norm: I'd be happy with a charter that broadly spoke of maintenance and
   possible requirements gathering with some explicit discussion of
   interaction with other working groups to consider possible cooperative

  XML processor profiles

   Henry joins by phone.

   Norm: I think we're in good shape. I like the document. I discussed it
   informally with the TAG over lunch.

   Norm summarizes his informal discussion with the TAG over lunch. Has
   agreed to write another document, one that builds on the profiles document
   to say what a processor that receives an application/xml document should

   Norm: There's still a desire to have a document that says more along the
   lines of "XML Functions", but it doesn't have to be this document and it
   doesn't have to be a normative product of this WG.
   ... I agreed that I'd work on such a document.

   <ht> I will help if we can actually figure out a ToC for the proposed
   additional doc't

   <ht> I remain unconvinced that there is a coherent topic short of a PhD
   thesis in scope

   Norm: Henry, did you get a chance to review the DoC?

   <ht> I did look

   <ht> I believe all are closed

   Norm: Next steps: clean up the typo, republish as a Last Call with an
   explicit note that we plan to go directly from LC to PR. Explicitly ask
   David and Bjorn if they're content with the resolutions.

   <scribe> ACTION: Henry to produce such a Last Call draft. [recorded in

   <scribe> ACTION: Henry to close the issues on the DoC that we believe are
   resolved. [recorded in


   Some discussion of the XML Calabash "iterate-to-fixed-point" step.

   Alex points out that his use case, combining the entries of a paginated
   Atom feed into a single feed isn't well-served by this step.

   Mohamed suggested that the p:iterate step will provide a way to do the
   pagination use case easily.

   Florent observes that if you have p:iterate you can implement fixed-point
   iteration with it.

   Mohamed: The p:iterate step will iterate over a sequence, but if the
   fixed-point case is a useful case, then we can probably make that work.

   <scribe> ACTION: Mohamed to write up a proposal for p:iterate (along the
   lines of xsl:iterate from XSL 2.1) [recorded in

  More future step possibilities

   Norm: We can't add new compound steps until V.next, but there are some we
   could write up as possibilities

   Some discussion of the restriction on where p:variables can appear. We
   successfully convinced ourselves that we needed the restriction :-)

   Some discussion of dependencies

   It might be nice to have a partition element that simply ensures that all
   of the steps in one partition run before/after all the ones in another

   Adjourned for the day.

   Time passes. Night falls.

   Reconvened on 5 November 2010.

  Investigating methods for making pipelines easier to build

   Vojtech: We're reimplementing the DITA toolkit in XProc (instead of
   Ant+Java extensions)
   ... It's about 9000-10000 lines of XProc
   ... Top-level pipeline consists of about 20 steps
   ... If you didn't want to do, for example, conref processing (one of the
   steps in the middle)
   ... how would you turn that off or replace that with something else?
   ... Suppose you want to do it just slightly differently
   ... Currently only option is to cut-and-paste the entire pipeline and
   change the one part I want to change.
   ... It would be nice if you could pass a step in dynamically or do some
   sort of replacement

   Alex: Or pass in a subpipeline

   Norm: The problem is that there's no obvious, single step that you want to
   override, you need to access them all

   Vojtech: Even if they copy-and-paste to change the definition of a
   pipeline, the original pipeline may be called from somewhere else where
   they have no control.
   ... It would also be nice to have library-level variables or constants.

   Norm: I can imagine we might do that...

   Mohamed: But it's not really variables, you want to override them, so it's
   more like parameters or options.

   Norm: That could get messy.

   More discussion

   Vojtech: I really want to replace all steps of a given type, not just a
   single instance.

   Florent: It seems that there are two aspects here: the ability to override
   an entire step type (like XSLT import precedence) and the ability to
   modify the internals of one type.

   Norm: Maybe you could make it work with just a mechanism to override whole
   step types. If you want to override only some, you can conditionalize the

   Mohamed: But how would you know what instance it was?

   Norm: Yes, I think we'd have to provide a function to get the step name.

   Alex: Sometimes the pipeline author knows where the extension points are,
   where the author is making choices, and that's maybe slightly different.

   Norm: That's where p:eval would be useful. You could let users pass in a
   ... You can kind of do that today by putting in calls to step types that
   are undefined, then the user has to import both your pipeline and
   declarations for those types.
   ... (I wonder if that's actually true)...

   Alex: It might be nice if we could make that easier; some mechanism for
   declaring steps "abstract" and then some mechanism for defining them when
   you import the pipeline.
   ... I wonder if users will be able to find ways to define where their
   extension points need to be or if we'll need a "redefine" mechanism.

   Mohamed: I don't think I want to see the ability to change a single
   instance of a type, but being able to change a whole type seems like
   something I might want to see.

   Norm: Isn't this just like what we were talking about in XSLT WG about
   overriding templates?

   Mohamed: Yes.

   Norm: Ok. I'm not dreaming.

  "Streaming" XProc

   Mohamed: The idea is the same as it was at the beginning of XProc. Being
   able to sort out, whatever we call it, saying how you can make your
   pipeline more streamable.
   ... We already say that if you use last(), you've probably impacted
   streaming in the pipeline.
   ... It would be nice if we had a document that described a profile of
   XProc that would improve streamability.
   ... Innovimax is working on an implementation of XProc using
   multi-threading and streaming.
   ... We are planning to issue the project at the end of March. It is based
   on XML Calabash. We already have some interesting results.
   ... We're working at the same time on a streamable subset of XPath with a
   different research agency.
   ... We have customers with large volumes of data that can't use DOMs and
   they can't rewrite all their tools.

   Norm: That could be interesting. If you had a defined streamable subset of
   XPath, you could have a switch to analyze a pipeline for streamability.

   Mohamed: Like the work we're doing in XSLT 3.0 now for streaming, we
   should be looking at XProc with streaming in mind.

   Alex: It always depends on what you mean by streaming. What's your bound?

   Some discussion of the value (or not) in defining a streamable subset of
   XPath (whatever that means)

   Florent recounts the example in XSLT of two XPath expressions interacting
   in ways that prevent streaming even though the expressions are simple.

   Discussion leads to general agreement that a study of use cases is
   necessary and would be valuable.

   Mohamed: Having a spec is only the first step. The second step is to have
   a document that describes usage patterns that will improve performance.

   Mohamed suggests that we could have a workshop on pipeline performance.

   Norm: So do we want to ask Liam to put something in the charter about
   investigating streaming or performance?

   General nods of agreement.

  More discussion of possible extension steps

   <scribe> ACTION: Alex to review common concurrency patterns to see what
   might work best for us (.e.g. countdown latches) [recorded in

Summary of Action Items

   [NEW] ACTION: Henry to close the issues on the DoC that we believe are
   resolved. [recorded in
   [NEW] ACTION: Henry to produce such a Last Call draft. [recorded in
   [NEW] ACTION: Mohamed to propose new text for the public XProc page.
   [recorded in [36]http://www.w3.org/2010/11/04-xproc-minutes.html#action03]
   [NEW] ACTION: Mohamed to write up a proposal for p:iterate (along the
   lines of xsl:iterate from XSL 2.1) [recorded in
   [NEW] ACTION: Norm to draft an erratum to add xml:id to the
   implementation-defined features list. [recorded in
   [NEW] ACTION: Norm to propose an erratum to fix p:xpath-context [recorded
   in [39]http://www.w3.org/2010/11/04-xproc-minutes.html#action02]
   [NEW] ACTION: Alex to review common concurrency patterns to see what might
   work best for us (.e.g. countdown latches) [recorded in

   [End of minutes]


    Minutes formatted by David Booth's [41]scribe.perl version 1.135 ([42]CVS
    $Date: 2010/11/08 16:35:17 $
    Hand edited by the scribe.


   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2010/11/04-05-agenda
   3. http://www.w3.org/2010/11/04-xproc-irc
   4. http://www.w3.org/2010/11/05-xproc-irc
   5. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#agenda
   6. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item01
   7. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item02
   8. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item03
   9. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item04
  10. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item05
  11. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item06
  12. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item07
  13. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item08
  14. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item09
  15. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item10
  16. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item11
  17. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item12
  18. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item12b
  19. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item5-01
  20. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item5-02
  21. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#item5-03
  22. http://www.w3.org/XML/XProc/2010/11/04-05-minutes#ActionSummary
  23. http://www.w3.org/XML/XProc/2010/11/04-05-agenda
  24. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2010Oct/0017.html
  25. http://www.w3.org/XML/XProc/2010/05/wd-comments/
  26. http://www.w3.org/2010/11/04-xproc-minutes.html#action01
  27. http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2010Sep/0003.html
  28. http://www.w3.org/2010/11/04-xproc-minutes.html#action02
  29. http://www.w3.org/2010/11/04-xproc-minutes.html#action03
  30. http://www.w3.org/2010/11/04-xproc-minutes.html#action04
  31. http://www.w3.org/2010/11/04-xproc-minutes.html#action05
  32. http://www.w3.org/2010/11/04-xproc-minutes.html#action06
  33. http://www.w3.org/2010/11/05-xproc-minutes.html#action01
  34. http://www.w3.org/2010/11/04-xproc-minutes.html#action05
  35. http://www.w3.org/2010/11/04-xproc-minutes.html#action04
  36. http://www.w3.org/2010/11/04-xproc-minutes.html#action03
  37. http://www.w3.org/2010/11/04-xproc-minutes.html#action06
  38. http://www.w3.org/2010/11/04-xproc-minutes.html#action01
  39. http://www.w3.org/2010/11/04-xproc-minutes.html#action02
  40. http://www.w3.org/2010/11/05-xproc-minutes.html#action01
  41. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  42. http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 8 November 2010 16:37:26 UTC

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