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

XProc Minutes 28 August 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 03 Sep 2008 09:32:48 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m23akhpd6n.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/08/28-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 123, 28 Aug 2008


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 4 Sep 2008?
         4. Action items
         5. Last Call comments
         6. Item 001
         7. Item 002
         8. Item 003
         9. Item 007
        10. Item 008
        11. Item 013
        12. Item 014
        13. Item 015
        14. Item 016
        15. Item 017
        16. Item 019
        17. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/08/28-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/08/14-minutes


  Next meeting: telcon 4 Sep 2008?

   Rui gives regrets for 4 Sep

   Norm gives regrets for 11 Sep; Henry will chair if there's a call.

  Action items

   Norm: Henry is working to get our charter extended through December to
   align with the other XML WGs.

  Last Call comments

   -> http://www.w3.org/XML/XProc/2008/08/lastcall/

  Item 001

   Norm: I think there's only one item, making the step naming rules
   ... I think we made them normative on purpose and we're unlikely to want
   to change them.

   Henry: I think that's the right thing to do. It gives us a basis for
   describing steps in URIs if anyone ever wants to.

   Proposal: Make no change.


  Item 002

   Norm: Also from Jim, a request for namespace aliasing instead of
   ... I don't want to make this change.

   Alex: He's asking for something that's related, but not the same as

   Henry: The only possible virtue I can see is that it might save you some
   typing if you happened to have the prefixes in scope.
   ... I don't think his proposal is substantially different, so why make the

   Norm: Ok, I'll see if that satisfies him.

  Item 003


   Norm: This is about RDF and there are some suggested step types here.

   Henry: I think we should respond as positively as possible and suggest
   that absolutely, the Semantic Web Deployment WG should publish a pipeline
   library with these steps defined as soon as possible.

   Norm: I agree, I think the best thing we can do is suggest that the folks
   with the relevant expertise publish the library.

   Henry: They'll get all the interop they need by doing it that way, using a
   W3C URI for the step namespace.

   Norm: I think we might get some pushback that they would like this to be
   in p: and in V1, but I'm not sure we can practically satisfy that request.

   Proposal: Suggest that this is something that folks with the relevant
   experience undertake asap, but that we won't plan to include it in p: in


  Item 007

   Norm: This is from Vojtech, who gave regrets, but I think I can describe
   ... Vojtech observes that p:load requires support for http: and file: URIs
   and wonders if p:data should do the same.


   Mohamed: There are now three locations where we need to be clear on what
   schemes are supported, p:load, p:http-request, and p:data

   Norm: And p:document, as it happens.
   ... It seems odd to call out http: and file:, but maybe it's useful for

   Alex: I think it's useful.

   Norm: Does it make sense to rephrase this as general note along the lines:
   implentations are encouraged to support all practical schems for loading
   resources, and in particular they SHOULD support file: and http(s): URIs.

   Mohamed: That's fine for me.

   Richard: I can imagine an implementation that doesn't have any files

   Norm: Sure, but then that's a good reason not to obey the SHOULD.

   Proposal: Make a general note as outlined above.
   ... and adjust the spec accordingly.


  Item 008

   Norm: I'm inclined to agree, but I'm not sure what the available APIs
   actually provide.

   Henry: Well, that's critically important. I'm less inclined to do this if
   there's no way to implement it.

   Norm: Ok, I'll investigate.

   <scribe> ACTION: Norm to investigate RELAX NG APIs for switches to control
   DTD Compatibility conformance. [recorded in

   Item: 012

   Norm: I just wanted to confirm that the WG agrees with me that an XSLT 2.0
   step is free to produce PSVI-rich results even if @psvi-required appears
   no where.
   ... Even if you said psvi-required=false, a step can still produce
   PSVI-rich infosets.
   ... Extra PSVI stuff shouldn't cause any problems.

   Henry: Seems right. Do we need to change anything?

   Norm: Maybe just add some editorial clarity.

   Mohamed: We can put psvi-required on declaration, library, and pipeline.
   But not on individual steps.

   Norm: Interesting, that's true, these are declaration-level attributes,
   not instance level.
   ... But maybe that's ok, there's no value in having a single step in the
   middle of a pipeline require PSVI support. I don't think.
   ... So I guess the question remains, if you say psvi-required=false, is it
   an error to produce a PSVI?

   Henry: I don't think so, in fact a PSVI capable processor might just
   ignore psvi-required.

   Proposal: Add some editorial clarification.


  Item 013

   Norm: I think the salient point is that we should say that how options and
   parameters are bound outside the pipeline is implementation-defined.

   Proposal: Say so.


  Item 014

   Mohamed: The example uses p:namespaces where it isn't needed.

   Norm: Let's let the editor reconsider the example

   Mohamed: I think the example predates the default rule, and that's the

   <scribe> ACTION: Norm to reconsider and fix this example [recorded in

   Mohamed: Vojtech observes that it's not clear when we use the short format
   for the option.

   Norm: If you use the short form then you can't use p:namespaces, so you
   better not need it.

  Item 015

   Norm: This encrypt/decrypt and I'm trying to work with the Security WG to
   resolve this one.
   ... We do have a use case in our requirements document that requires it.

   Mohamed: That's why I've proposed to not normalize too much, maybe we
   should just say that's what parameters are for, to say

   Norm: Yeah, but having a standard step with no interoperability is a
   little funky.
   ... If the Security WG can help us get these crisp, then we'll prbably
   need to include them, otherwise, we'll have to do something else, maybe
   what we're suggesting for the RDF steps.

   Henry: Maybe at TPAC08 we can hand this off to Frederick if we promise to

   Norm: That's not a bad idea either.
   ... I think we should just leave this open a little longer.

  Item 016

   Mohamed: I found two or three things that weren't in sync. For example,
   for p:insert, I proposed to accept different kinds of nodes depending on
   the position option.

   Norm: I see what you mean, but there are no constraints on p:insert so we
   can just let the invalid document catch it, right?

   Mohamed: What about matching a PI before the document element

   Norm: Oh, right. I see. I guess that should really be anything except
   attribute nodes.

   Proposal: Fix p:insert

   Mohamed: And p:replace should be the same.

   Richard: It should only allow you to match things that can appear on the
   child axis.

   Norm: But matching a document node and inserting a comment as the
   first-child is a reasonable thing, right?

   Richard: It doesn't make any sense to insert something before or after the
   *document node*

   Norm: I'll have to expand the prose a bit.

   <scribe> ACTION: Norm to take another crack at getting this right for all
   the steps. [recorded in

   <ht> I like Richard's formulation: p:insert allows matching of anything
   which may have children if where is first or last, and anything that _is_
   a child if where is before or after

  Item 017

   Norm: We need a normative reference for UUIDs, anyone know what it is?

   Alex: There's an ISO standard
   ... It's in the references for the RFC 4122

   Norm: Ok, I just looked right past that when I scanned the references.

   Proposal: Add the reference

   Henry/Alex: Maybe we can refer to both, because the RFC is easier to read?

   <MoZ> [3] ISO/IEC 9834-8:2004 Information Technology, "Procedures for the

   <MoZ> operation of OSI Registration Authorities: Generation and

   <MoZ> registration of Universally Unique Identifiers (UUIDs) and their

   <MoZ> use as ASN.1 Object Identifier components" ITU-T Rec. X.667,

   <MoZ> 2004.

   Norm: I don't mind having the RFC in the non-normative references.


  Item 019

   Proposal: Say they're hex


  Any other business?

   Henry: We've been glibly addressing these issues without classify the
   changes. I think the way we've proceeded has been perfectly fine.
   ... At some point we'll have to decide.

   Norm: I think we've been making clarifications and small changes.

   Henry: Strictly speaking, anything that invalidates a review is out of

   Norm: I don't want to make any of those.
   ... If I think anything I change in the spec isn't a clarification, I'll
   bring it back to the WG.

   Mohamed: Probably you should make an announcement that there's an

   Norm: Okie dokie.

   Henry: Have we invited review of the spec?

   <scribe> ACTION: Norm to make sure we've solicited review from the
   relevant WGs [recorded in


Summary of Action Items

   [NEW] ACTION: Norm to investigate RELAX NG APIs for switches to control
   DTD Compatibility conformance. [recorded in
   [NEW] ACTION: Norm to make sure we've solicited review from the relevant
   WGs [recorded in
   [NEW] ACTION: Norm to reconsider and fix this example [recorded in
   [NEW] ACTION: Norm to take another crack at getting this right for all the
   steps. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/08/28-agenda
   [3] http://www.w3.org/2008/08/28-xproc-irc
   [9] http://www.w3.org/2008/08/28-xproc-minutes.html#action01
   [10] http://www.w3.org/2008/08/28-xproc-minutes.html#action02
   [11] http://www.w3.org/2008/08/28-xproc-minutes.html#action03
   [12] http://www.w3.org/2008/08/28-xproc-minutes.html#action04
   [13] http://www.w3.org/2008/08/28-xproc-minutes.html#action01
   [14] http://www.w3.org/2008/08/28-xproc-minutes.html#action04
   [15] http://www.w3.org/2008/08/28-xproc-minutes.html#action02
   [16] http://www.w3.org/2008/08/28-xproc-minutes.html#action03
   [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [18] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[17] version 1.133 (CVS
    $Date: 2008/09/03 13:31:53 $

Received on Wednesday, 3 September 2008 13:33:37 UTC

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