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

Re: XProc Minutes: 4/5 Nov 2010

From: Innovimax W3C <innovimax+w3c@gmail.com>
Date: Mon, 8 Nov 2010 19:55:15 +0100
Message-ID: <AANLkTikKLevTMaQfK_Odj1QKXvD89QHegJ2tpezG3WHb@mail.gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org
Norm,

It seems the discussion around p:quote('&apos;', $foo) and
p:quote('&quot', $foo) has disappeared

The idea was to allow proper quoting and escaping  of a string

so that

p:quote('&apos;', $s as xs:string()) as xs:string() will return the
content of $s preceded and followed with &apos; and where &apos; in $s
are carefully escaped

The symmetry apply to

p:quote('&quot;', $s as xs:string()) as xs:string()

Mohamed

On Mon, Nov 8, 2010 at 5:36 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> See http://www.w3.org/XML/XProc/2010/11/04-05-minutes
>
> [1]W3C
>
>                  - DRAFT -
>
>              XML Processing Model WG
>
> Meeting 183, 04-05 Nov 2010
>
>  [2]Agenda
>
>  See also: IRC logs, [3]04 Nov and [4]05 Nov.
>
> Attendees
>
>  Present
>      Norm, Vojtech, Alex, Florent, Mohamed, Carine, Henry (on the phone
>      for item 11)
>
>  Regrets
>      Henry, Paul, Jeni
>
>  Chair
>      Norm
>
>  Scribe
>      Norm
>
> Contents
>
>   * [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
>
>  Accepted.
>
> Accept minutes from the previous meeting?
>
>  ->
>  [24]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2010Oct/0017.html
>
>  Accepted.
>
> 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
>  later)
>
> 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.
>
>  Accepted.
>
> 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
>  [26]http://www.w3.org/2010/11/04-xproc-minutes.html#action01]
>
>  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
>  implementation-defined
>
>  Proposal: No technical changes, just clarify that xml:id is an
>  implementation-defined feature
>
>  Accepted.
>
> Shouldn't choose report err:XD0026 too?
>
>  ->
>  [27]http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2010Sep/0003.html
>
>  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.
>
>  Accepted.
>
>  <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:document-template.>
>
> <p:in-scope-names>
>  <p:output port="result" primary="false"/>
> </p:in-scope-names>
>
>  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
>  implementation-dependent.
>
> <p:document-template>
>  <p:input port="template"/>
>  <p:input port="source" sequence="true" primary="true"/>
>  <p:input port="parameters" kind="parameters"/>
> </p:document-template>
>
>  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
>    undefined."
>
>   * 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">
>   <c:body>
>    <h:div>...</h:div>
>   </c:body>
>  </c:request>
>
>  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
>  /h:html/h:body/h:div[3]).
>
>  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:document-template>
>   <p:input port="template">
>    <p:inline>
>     <c:request method="{$method}" href="{$uri}"
>          username="{$user}" password="{$password}">
>      <c:body>
>       { /h:html/h:body/h:div[3] }
>      </c:body>
>     </c:request>
>    </p:inline
>   </p:input>
>   <p:input port="source" sequence="true">
>    <p:pipe step="main" port="result"/>
>   </p:input>
>   <p:input port="parameters">
>    <p:pipe step="vars" port="result"/>
>   </p:input>
>  </p:document-template>
>
>  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
>  work?
>
>  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
>  activities.
>
> 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
>  do.
>
>  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
>  [30]http://www.w3.org/2010/11/04-xproc-minutes.html#action04]
>
>  <scribe> ACTION: Henry to close the issues on the DoC that we believe are
>  resolved. [recorded in
>  [31]http://www.w3.org/2010/11/04-xproc-minutes.html#action05]
>
> Iteration
>
>  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
>  [32]http://www.w3.org/2010/11/04-xproc-minutes.html#action06]
>
> 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
>  partition
>
>  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
>  internals.
>
>  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
>  pipeline.
>  ... 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
>  [33]http://www.w3.org/2010/11/05-xproc-minutes.html#action01]
>
> Summary of Action Items
>
>  [NEW] ACTION: Henry to close the issues on the DoC that we believe are
>  resolved. [recorded in
>  [34]http://www.w3.org/2010/11/04-xproc-minutes.html#action05]
>  [NEW] ACTION: Henry to produce such a Last Call draft. [recorded in
>  [35]http://www.w3.org/2010/11/04-xproc-minutes.html#action04]
>  [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
>  [37]http://www.w3.org/2010/11/04-xproc-minutes.html#action06]
>  [NEW] ACTION: Norm to draft an erratum to add xml:id to the
>  implementation-defined features list. [recorded in
>  [38]http://www.w3.org/2010/11/04-xproc-minutes.html#action01]
>  [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
>  [40]http://www.w3.org/2010/11/05-xproc-minutes.html#action01]
>
>  [End of minutes]
>
>  --------------------------------------------------------------------------
>
>  Minutes formatted by David Booth's [41]scribe.perl version 1.135 ([42]CVS
>  log)
>  $Date: 2010/11/08 16:35:17 $
>  Hand edited by the scribe.
>
> References
>
>  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/
>



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Monday, 8 November 2010 18:55:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 November 2010 18:55:53 GMT