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

XProc Minutes 27 Sep 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 27 Sep 2007 12:08:26 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ve9way6d.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/09/27-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 85, 27 Sep 2007


   See also: IRC log[3]


           Norm, Paul, Rui, Alessandro, Murray, Mohamed

           Michael, Richard, Henry




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 4 October 2007
         4. Review of XSLT streaming specifications
         5. p:add-xml-base
         6. Scope of step types
         7. Is a conformant processor supposed to raise xml:id or xml:base
         8. Wrapping of nodes into a document
         9. <input> for <pipeline>
        10. Scope of stpe names
        11. Viewport
        12. pipeline library
        13. Saxonica comments, sections 1 and 2
        14. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/09/27-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/09/13-minutes


  Next meeting: telcon 4 October 2007

   Murray gives regrets.

  Review of XSLT streaming specifications

   Mohamed: It's the requirements document that's ready for review.

   Murray will take a look.

   Norm: Thanks, Murray.



   Comments list:

   <MoZ> here is the last requirements for XSLT Streaming

   Norm wonders what the intended semantics of the "all" option were.

   <scribe> ACTION: Norm to investigate the intended semantics of "all" on
   p:add-xml-base [recorded in

  Scope of step types


   Norm: I think we only meant for types declared in the pipeline and in the
   imported libraries, not recursively.

   General agreement.

   <scribe> ACTION: Norm to clarify the scope of step types [recorded in

  Is a conformant processor supposed to raise xml:id or xml:base errors


   Mohamed: We allow xml:base and xml:id everywhere in the pipeline document,
   so what is the processor supposed to do if there are xml:id or xml:base

   Norm: I understand xml:id errors, but what are xml:base errors?

   Mohamed: I was thinking of bad characters or bad URIs.

   Norm: I'm of two minds.

   Paul: If it doesn't have anything to do with the pipeline, I don't see why
   we should give errors for it.

   Norm: This is about xml:id attributes *in the pipeline*

   Paul: This is a metaissue, it's the pipeline parser that will see the

   Norm: I'm not inclined to make it a fatal error.

   Murray: Do we use the xml:ids?

   Norm: No.
   ... Anyone want more aggressive rules in XProc?


  Wrapping of nodes into a document


   Norm: So we should say "element, processing-instruction, or document
   nodes", yes?

   Mohamed: That would be half the question, but the other half would be to
   say on the select that only nodes of certain types will be wrapped as
   document nodes.

   Norm: So we need to make it clear that what is selected can be a document.

   Murray: It's clear to me that what appears on any output must be a
   document. A wrapper around a bunch of attributes is not a document.
   ... We've already established the rules, so we just need to clarify it.

   Alessandro: It could be one document or a sequence of documents.

   Norm: But I think Murray is right, we just need to clarify what select can

   <scribe> ACTION: Norm to clarify what select can select [recorded in

  <input> for <pipeline>


   Norm: Richard doesn't think that p:input on pipeline should have a
   ... But I think we intended the binding to be the default if no external
   binding was given.

   <scribe> ACTION: Norm to clarify the spec and follow up. [recorded in

  Scope of stpe names


   <MoZ> here :

   Norm: I'm content with Richard's editorial suggestion, anyone disagree?



   Norm: I think this got resovled in the thread

   No one disagrees.

  pipeline library


   Norm: So the question is, if you hand a pipeline *library* to a processor
   should it run a particular pipeline.
   ... Seems to me that the implementation should take an option to specify
   which library

   Rui: It's like make or ant, defaulting to a particular target.

   Murray: But we're not recreating Make here

   Rui: Some of the use cases are very similar

   Murray: I seem to recall having this discussion; we said you can run a
   pipeline by name; it feels wrong to run a library.

   Norm: I think the Make/ant use case is a little bit compelling

   Norm muses out loud about running the first pipeline

   Murray: If we're going to go down this road, I think we should provide
   explicit syntax.

   Norm: Do we want to provide explicit syntax for this?

   Alessandro: I'm not moved; I see why Make and ant do it, it doesn't seem
   like it's a very large distinction between a Makefile and a library that
   would be used; but we're having this distinction in XProc.
   ... So it makes sense to me that what you run is a pipeline not a library.

   Rui: You can run a jar file if the manifest gives a default class.

   <alexmilowski> +1

   Murray: I don't think we should do this as an afterthought; and I don't
   think we should do this.
   ... It seems like creeping featurism.

   Question: should we add a feature to establish the default pipeline in a

   Y: 2; N: 6 (3 concur)

   Norm: I don't see support for it. Anyone object to leaving it out of V1?

   Murray wonders what Richard and Henry would have said. Norm does too, for
   that matter.

  Saxonica comments, sections 1 and 2


   Norm: I'm inclined to agree with his first comment.
   ... On his second, we run afoul of starting names with "xml".

   Murray: I thought we wanted all the verbs to start with "validate".

   Norm: Oh, you're right, this way they sort together.

   Alex: So how about validate-with-...

   <ruilopes> p:validate-with-*

   Norm: Seems to me we have too choices; we could say "Oh, c'mon Mike..." or
   we could change them.

   Alessandro: I think validate-with would be clearer.

   <MoZ> +1 for validate-with-

   Murray: What about just "validate" and peek at the input?

   Alex: We decided we didn't want that.

   Norm: Anyone object to renaming them validate-with?

   <alexmilowski> validate-via-the-language-known-as-xml-schema


   <scribe> ACTION: Norm to put "parameters as strings" on next week's agenda
   [recorded in http://www.w3.org/2007/09/27-xproc-minutes.html#action05[22]]

   Alex: What about point 8?

   Murray: Do we need to have a section that makes our vagueness more

   <alexmilowski> "Infoset Processing

   <alexmilowski> At a minimum, an XML document is represented and
   manipulated as an XML Information Set. The use of supersets, augmented
   information sets, or data models that can be represented or conceptualized
   as information sets should be allowed, and in some instances, encouraged
   (e.g. for the XPath 2.0 Data Model).

   <alexmilowski> "

   <alexmilowski> We say that in our requirements document.

   Norm: What's now in 2.6.1 probably needs to be further up in the document

   Alex: I think we need to say something explicit about being based on the

   Murray: I think what goes between the steps is a putative XML document. It
   could be an infoset, it could be an XDM, it could be an XPath 1.0 NodeSet,
   it could be any number of different things. And it depends on your
   implementation how you're going to do that.
   ... We want you to bear in mind however, that it is something that could
   be mapped into an XML document. We're talking about a theoretical, or
   putative, document.

   Alex: That's what using infoset would give us.

   Norm: I think what we have in 2.6.1 is probably good enough, we should
   just move it up.

   <scribe> ACTION: Norm to ask Mike if he thinks that might be good enough.
   [recorded in http://www.w3.org/2007/09/27-xproc-minutes.html#action06[23]]

  Any other business



Summary of Action Items

   [NEW] ACTION: Norm to ask Mike if he thinks that might be good enough.
   [recorded in http://www.w3.org/2007/09/27-xproc-minutes.html#action06[24]]
   [NEW] ACTION: Norm to clarify the scope of step types [recorded in
   [NEW] ACTION: Norm to clarify [recorded in
   [NEW] ACTION: Norm to clarify the spec and follow up. [recorded in
   [NEW] ACTION: Norm to investigate the intended semantics of "all" on
   p:add-xml-base [recorded in
   [NEW] ACTION: Norm to put "parameters as strings" on next week's agenda
   [recorded in http://www.w3.org/2007/09/27-xproc-minutes.html#action05[29]]
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/09/27-agenda
   [3] http://www.w3.org/2007/09/27-xproc-irc
   [7] http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
   [8] http://www.w3.org/mid/46F97ED6.90908@u-turnmediagroup.com
   [9] http://www.w3.org/2007/09/27-xproc-minutes.html#action01
   [11] http://www.w3.org/2007/09/27-xproc-minutes.html#action02
   [14] http://www.w3.org/2007/09/27-xproc-minutes.html#action03
   [16] http://www.w3.org/2007/09/27-xproc-minutes.html#action04
   [22] http://www.w3.org/2007/09/27-xproc-minutes.html#action05
   [23] http://www.w3.org/2007/09/27-xproc-minutes.html#action06
   [24] http://www.w3.org/2007/09/27-xproc-minutes.html#action06
   [25] http://www.w3.org/2007/09/27-xproc-minutes.html#action02
   [26] http://www.w3.org/2007/09/27-xproc-minutes.html#action03
   [27] http://www.w3.org/2007/09/27-xproc-minutes.html#action04
   [28] http://www.w3.org/2007/09/27-xproc-minutes.html#action01
   [29] http://www.w3.org/2007/09/27-xproc-minutes.html#action05
   [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [31] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[30] version 1.128 (CVS
    $Date: 2007/09/27 16:07:32 $

Received on Thursday, 27 September 2007 16:09:17 UTC

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