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

XProc Minutes 31 Jan 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 31 Jan 2008 12:08:46 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ejbx7wip.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/01/31-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 100, 31 Jan 2008


   See also: IRC log[3]


           Alex, Paul, Rui, Alessandro, Norm, Henry, Richard, Mohamed





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 7 February 2008?
         4. Last Call Comments
         5. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/01/31-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/01/24-minutes


  Next meeting: telcon 7 February 2008?

   No regrets given

  Last Call Comments

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

   Comment 100: cherry picked items

   Should we add exclude-prefixes to serialization?

   Alex: It'd be nice, but there's no standard serialization control for it

   Henry: Why?

   Alex: XQuery doesn't have it.

   Norm: I don't have any recollection of a technical reason why it wasn't
   part of serialization.

   Alex: I don't see anything in the serialization spec about excluding

   Norm: Clearly it can be done, do we want to do this in XProc 1.0?

   Alex: It's critical if you want to send the output to IE.
   ... But implementors could do this outside of the spec.

   Norm: We could let implementors do this as an extension.

   Alex: It doesn't even have to be an extension in the pipeline; it could be
   in how you run the processor.

   Henry: Gee, this is on the margins.
   ... Fussing with namespaces and serialization is something on which one
   can waste arbitrary amounts of time.

   Alex: Implementors have lots of ways, it's a question of whether we make
   it a requirement.

   Henry: With my implementors hat on, I'd sort of rather not...

   Alex: Wouldn't an XSLT step at the end of the pipeline do it?

   Norm: I'm not sure.

   Richard: I'm not sure I understand the issue.
   ... In XSLT, exclude-result-prefixes is only about literal result elements
   in the stylesheet.

   Norm: Ok, so is there anything comparable?

   Ricahrd: If the pipeline itself binds some prefixes, then they're in scope
   for literal elements in it.

   Henry: Like an inline document.

   Some discussion of what the namespace bindings are for an inline document

   Alex: You could do this with a new step.

   Norm: I don't think we want to add this to serialization and I don't thnk
   we need to do it for any other reason.

   Henry: Someone is free to create a simplify-namespace step and we can
   adopt it for V.next if it's widely supported.

   Proposed: No, we aren't going to add anything for exclude-prefixes


   Next up, should the 'path' attribute on p:directory-list be renamed?

   Richard: If I were renaming this, I'd probably call it something like

   Norm: Nikolay followed-up proposing just "uri" on the basis that it might
   support ftp:, jar:, file:, etc.
   ... On that basis, I think I'd rather not change it.

   <MoZ> what about location ?

   Norm: Most implementations are only going to support file: URIs on the
   local host, so "path" makes some sense.

   Alex: Location?

   Richard: None of these is obviously better than "path".

   Proposal: No change.


   Adding a scheme to p:label-elements that generates an ID from an XPath

   Alex: That would require another option

   Some discussion

   Richard: I've found that you often want to combine all sorts of
   ... for example, an XPath that gives you the count. I did it with a C-like
   format-string. It gets passed the prefix, suffix, and label.

   Some discussion of the possibilities

   Richard: If prefix/suffix can be XPaths then in the XPath case you can
   just say that the label is '' so that you just get the concatenation of
   prefix and suffix.

   Henry: We can always use an XPath and just require implementors to
   short-cut the simple case.

   Alex: I think I'm with Henry, we take three options and we make them into

   <ht> pp:count-elements()

   <ht> It's nice that Alex likes my proposal, I like his

   Norm boggles at a step-local function.

   <ht> Use a variable

   Richard: I think it's entirely reasonable for steps to have local

   Henry: I like adding a variable. I like saying impl's must bind $p:index
   to a value for the evaluation of this expression.

   Norm boggles harder

   Richard: To say this adds something is no more true than saying that XSLT
   adds a bunch of stuff.
   ... From the pipeline perspective, it's just a string. The label-elements
   step is the one doing the evaulation.

   Norm: I think we've drifted far enough that we need a proposal.

   <scribe> ACTION: Alex to draft a proposal for this change. [recorded in

   <ht> HST believes the proposal is to replace 'prefix', 'suffix' and
   'scheme' with 'label', with default value concat('_',$p:index)

   Comment 102: Default bindings for non-primary inputs

   Norm tries to describe the proposal

   Alex: That is weird. That's not what you want in most cases.

   Proposal: Remove default bindings for non-primary inputs


   Comments 107: Options in XSLT match patterns

   Henry: If 2.8.1 doesn't apply, then don't we need to say something similar

   The question of whether prefix is in-scope or not is open

   Or maybe it isn't

   Mohamed: Can we say that XSLT match pattern in XProc doesn't allow
   variable references, even if it's in XSLT2.
   ... We leave it for V.next to say how we do this.

   Henry: Section 2.8.2 says explicitly that there aren't any variables in
   ... We can close this issue by saying, 'use select'.

   Richard: I'm now a bit confused by this description of the XPath context

   <ht> introduces 'select' and 'value' and explains that in-scope
   options are available for access by variable references in 'select'

   Richard: What 2.8.2 should say is "except when otherwise specified by the
   step documentation"

   <ht> should point out that per 2.8.2 if a option 'value' is used
   as an XPath, those bindings will _not_ be available

   Richard: In fact, almost all these things do say "unless otherwise
   specified by the step"

   Norm: Editorial carelessness

   Richard: In fact, the XPath 2 case says that, we just need to fix the
   XPath 1 case.

   Henry: We should be clear in about the value case and point to
   2.8.2 from there.

  Any other business



Summary of Action Items

   [NEW] ACTION: Alex to draft a proposal for this change. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/01/31-agenda
   [3] http://www.w3.org/2008/01/31-xproc-irc
   [7] http://www.w3.org/2008/01/31-xproc-minutes.html#action01
   [8] http://www.w3.org/2008/01/31-xproc-minutes.html#action01
   [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.133 (CVS
    $Date: 2008/01/31 17:07:00 $

Received on Thursday, 31 January 2008 17:09:00 UTC

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