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

XProc Minutes 22 Mar 2007

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 22 Mar 2007 12:16:02 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87wt19s18d.fsf@nwalsh.com>
See: http://www.w3.org/XML/XProc/2007/03/22-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

22 Mar 2007


   See also: IRC log[3]


           Norm, Murray, Alessandro, Andrew, Henry, Alex





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 29 Mar 2007
         4. Review of editor's draft
         5. Placement of ignored content?
         6. Import precedence
         7. Pipeline visibility
         8. Order of input/output/param/option
         9. Interpretation of type name on declare-step
        10. Review of the step library
        11. Output from components that currently have no output.
        12. Solution for the caching problem
        13. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/03/22-agenda.html


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/03/15-minutes.html


  Next meeting: telcon 29 Mar 2007

   No regrets given.

  Review of editor's draft

   -> http://www.w3.org/XML/XProc/docs/langspec.html

   Norm: Anyone think we can't publish this as a PWD?

   Henry: I'm worried that some of the XML examples are wrong.

   Norm: I'll fix the XML
   ... Any other showstoppers?

   None heard

   Norm: I went through the last week or so's mail and identified several
   issues that we've been discussing.

  Placement of ignored content?

   Norm: Can you put documention inside of p:pipe or p:document or p:inline?

   Murray: I think we should have an element dedicated to documentation
   instead of playing games with ignored prefixes.

   Norm: Having an element for documentation does not eliminate the need for
   ignored preixes.

   <Zakim> MSM, you wanted to agree with Murray

   Michael: I wanted to agree with Murray. You don't want to get rid of
   ignored content but you want to limit it to extensions.
   ... Documentation is a well understood need, so label it that.

   Norm: Mohamed also agreed in IRC

   Henry: I'm happy to leave the question of where documentation is allowed
   to the editor, but I don't want it to be allowed in p:inline. The p:inline
   content shouldn't have any special rules.
   ... If you don't want it to go through the pipeline, don't put it in

   Norm: I'm hearing a proposal to have p:documentation element that is just
   for documentation.

   Murray: You might want to spell it with a shorter word.

   Norm: Such as?

   Murray: p:readme?

   Norm: I don't like that one, how about p:doc?

   <MSM> [p:doc works for me]

   Norm: Everybody happy with p:doc?


   Norm: Do we now want to rename "ignored-prefixes", "extension-prefixes"

   Murray: What for?

   Norm tries to explain.

   Norm: I don't think we have to worry about where p:ignored-prefixes is
   allowed or any defaults for ignored prefixes now that we have a
   documentation element.

  Import precedence

   <ht> HST agrees, subject to my comment about p:inline. . .

   Norm: The question is, should you be to declare a step or define a
   pipeline with the same name as some declared step or pipeline that you
   imported from a library.

   Henry: It seems relatively cheap but relatively unlikely to be useful. But
   it's probably better than ignoring the issue.

   Murray: I'm worried about the security issue and spoofing of pipelines.

   <ht> OK, so A imports and overlays part of B, and I import A and B, what
   do I get?

   Murray: If your library imports Alex's, but you've put some subtle change
   in, maybe you can steal data from me. Or maybe I'll have a hard time
   debugging it.

   Henry: I'm convinced, let's not doit.

   Norm: Me too.

  Pipeline visibility

   Norm: Can two pipelines defined in the same library see each other?

   Murray: Yes, of course.

   Norm: I think a consequence of this is that order no longer matters.
   ... So you can't do a single pass, you have to be prepared to encounter
   qnames for pipelines that you haven't seen declarations for yet.

  Order of input/output/param/option

   Norm: Do we define the content of step with a sequence or a choice group?

   Murray: What Jeni says makes sense


   Murray: I think you have to have all the declarations first

   Henry: I think it's pointless to allow variability of only limited

   Murray: I want them to be in any order, as long as they come before the
   first step.
   ... While I can somewhat appreciate Henry's position, I don't see that
   there's any great cost.

   Henry: I don't feel strongly.

   Norm: Anyone strongly in favor of the status quo?
   ... Ok, let's change it for the next draft and add a note to the spec
   soliciting feedback on this point.

  Interpretation of type name on declare-step

   Norm: Is an unprefixed name in the type attribute of p:declare-step
   implicitly in the default namespace a la Schema rules, or in no namespace,
   a la XSLT rules.
   ... Henry, you wanted the Schema rules, Alessandro, Alex, and Norm prefer
   the XSLT rules.
   ... Anyone other than Henry arguing for the schema rules?

   Murray: I'm confused.

   Norm tries to explain.

   Murray: If I now write a pipeline and I want to use that process and I
   have a namespace bound to the prefix, example:

   <Zakim> ht, you wanted to make the Dan Connolly point

   Henry: If we adopt the proposal, then some names won't be in any namespace
   and as Dan Connolly observes, all things should be have a URI.
   ... We're in an inconsistent position for libraries which is the full
   equivalent of the schema position.
   ... I prefer the following summary of the schema rules: whenever something
   is a reference, the full namespace bindings are available, but for naming
   things you don't use the namespace bindings at all.
   ... That's what we did for pipelines and libraries, but not what we've
   done for types, so I'm in an impossible position.

   Norm: We don't need to answer this for the next draft, so I'm going to
   move on.

   Murray: Ok, though I'm tending to lean towards Norm's answer because I
   think XSLT is going to be closer than Schema for our users.

  Review of the step library

   -> http://www.w3.org/XML/XProc/docs/langspec.html#std-components

   Norm: I sent in some minor comments, Henry did to. Alex, did you get
   anything off list?

   Alex: No, not really.

   Norm: Any components that anyone would prefer not to see in the next
   working draft?

   Henry: Yes, if we're not going to settle the caching question until after
   this draft, then we should remove the xinclude-with-sequence component.

   Alex: I'm happy to exclude it for now.

   Henry: I support the sequence of schemas
   ... We looked at the minor components for most of a telcon (when I was
   chairing pro-tem)
   ... I'm not sure we've ended up with all the things we talked about.

  Output from components that currently have no output.

   Norm: Murray suggested that the components that currently have no output
   could usefully have a single output that identifies the location where the
   content was actually written.

   Henry: Yes, it does mean that components that succeed always have output.

   Norm: Can you update the draft along those lines, Alex?

   Alex: I wonder if we could use this to deal with non-XML results from
   ... This and the httpRequest object have their own sort of component

   Norm: I'm happy if you put the result in a component results namespace or

   Proposal: The editors shall incorporate the decisions made today and the
   resulting draft will be published as the next public working draft.


   Alex: We didn't talk about the XSL-FO component, are we adding it?

   Norm: Any objections?

   None heard. Go for it.

  Solution for the caching problem

   Norm: I think there are three options: do nothing, you can't; do the
   *-with-sequence thing; or do some form of caching.

   Murray: I think we should do nothing. Too clever by half.

   <MSM> [and in that case, give it the name Y-Include, also spelled "why

   Henry: In certain cases, because tools expect to reference things by URI,
   and pipelines may want to compute those resources, that the ability to
   assing URIs to things as they flow through the pipeline and then getting
   access to those things by URI, in the case where that's what you want to
   do, seems to be valuable.
   ... We could say "no, in V1". I'm opposed to doing it across the board
   because it blows away streaming.
   ... You have to cache everything that comes out.
   ... That's much too high a burden. So my proposal was to adopt an
   intermediate position, allowing authors to do caching for a part of the

   Norm: I think we could decide not to do something for V1, but I'm really,
   really reluctant to go there. I think it's horribly near a requirement.

   Alex: I think caching is the right way to proceed but not for V1.

   <ht> HST: I want to be able to set the base URI to "#banana", i.e., not
   written out _anywhere_!

   Murray: I assume that if I do a store, I should be able to refer to that
   thing later.

   Norm: That's caching.

   Henry: The "later" doesn't have any real meaning in our specification.

   Norm: We're out of time, we'll come back to this next week if we haven't
   finished it in email.

  Any other business?

   None. Adjourned.

Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/03/22-agenda.html
   [3] http://www.w3.org/2007/03/22-xproc-irc
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[9] version 1.127 (CVS
    $Date: 2007/03/22 16:13:57 $

Received on Thursday, 22 March 2007 16:16:31 UTC

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