XProc Minutes 19 July 2007

See http://www.w3.org/XML/XProc/2007/07/19-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 75, 19 Jul 2007


   See also: IRC log[3]


           Paul, Norm, Rui, Alessandro, Alex, Andrew, Mohamed

           Richard, Henry




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 26 July 2007
         4. Review of 17 July 2007 draft.
         5. "Minimum" set of serialization options
         6. p:map proposal.
         7. p:make-uris-absolute proposal
         8. p:add-xml-base-attributes proposal
         9. Grouping in p:wrap-sequence
        10. Making href optional on p:log proposal
        11. Questions about defaulting and syntactic shortcuts
        12. Questions about xsl:message from XSLT
        13. Issues between here and Last Call:
        14. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/07/19-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/07/12-minutes


  Next meeting: telcon 26 July 2007

   Norm, Rui (for three weeks) give regrets, Paul to chair

  Review of 17 July 2007 draft.

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

   No comments

  "Minimum" set of serialization options


   Alex: There's not a lot of flexibility in the serialization spec.
   ... The spec is very clear about what you can/can't do in each method
   ... I plan to create a section to outline the serialization options.
   ... I'll also clarify the semantics of the options

   Norm: We still have some flexibility; we can specify default values and
   not require any other values to be supported.

   Alex: Even if we enumerate the defaults; the problem is that if we have
   these options users may use them

   Norm: I'm suggesting that we just don't require that all the options be

   <MSM> [Sanity check - Norm is talking about a floor, not a ceiling,

   Uh. Yeah.

   Norm gives up; will wait for concrete text to comment on

   Michael: I'd paraphrase by saying that we don't need to require anything
   that serialization doesn't require us to require. I think it would be
   useful to have a list of the things that host languages are required to
   require. I think that's App D of the Serialization spec.
   ... We don't need to require implementations to support some of those if
   they're tedious.

   Alex: Appendix D is a checklist of impl. defined features. I thought Norm
   was more concerned about the minimum bar for features.

   Michael: The set of features is partitioned into things that impl. are
   required to support, ones that a language could support, and features
   which the serialization spec leaves implementation-dependent.

   <alexmilowski> "The values NFC and none MUST be supported by the

   <MSM> Section 10 says of host languages: "Specifications that set
   conformance criteria for their use of Serialization MUST NOT change the
   semantic definitions of Serialization as given in this specification,
   except by subsetting and/or compatible extensions. It is the
   responsibility of the host language to specify how serialization errors
   should be handled."

  p:map proposal.


   Mohamed: It has had a lot of names, map, catalog, etc. The need was
   identified a long time ago, especially for xinclude-with-sequence. The
   proposal was to make a tool which can help defining a mapping between
   documents available and URIs.
   ... Maybe it's a bit too much for V1. Maybe we need to get more
   experience. A lighter version might be useful for defining mappings for
   ... For V1 in XSLT 1.0, we don't have access to the document created by
   result-document extensions.
   ... It seems like there are a lot of use cases where there would be value
   in being able to provide hints to the pipeline.
   ... The other point was, even if we don't care about p:map or something,
   are we going to say something about how consistent resolution of names is
   within a pipeline.
   ... I think we need to open this box and try to draft something.

   Norm: I thought years ago that we were going define a "pool" from which
   steps would get their URIs.
   ... It became clear that we wouldn't get consensus on that.

   Alex: I'm sympathetic, I just don't think we can do that in V1.
   ... I can solve this by orchastrating a couple of pipelines.
   ... We'll learn if we really need a language construct for this.

   Norm: I think there's risk of pain to users, but a lot of benefit in
   waiting for V2

   Mohamed: So what's the proposed answer? Just implementation-defined.

   Norm: Yes, implementation-defined, with maybe a note about the value of
   the ability to get access to URIs.

   Some discussion of how this interacts with the proposed base-uri and
   make-absolute steps.

   Mohamed: I'm still unsure, but maybe we should just move on.

   Alex: It gives people the flexibility to use proxies, caches, etc.

   Mohamed: I just want to be sure that every place we have URI, we can use a
   condition to know which implementation we're running.

   <MSM> [it's important to give people some flexibility - but it's also
   important to give users of the term "conforming processor" a useful term
   defining a useful class of processor -- the utility of the phrase
   "conforming processor" is really the only thing any spec has to sell]

   Norm: I don't hear consensus to add a step or language feature in V1.

   Mohamed: I agree. I just want the spec to be clear about resolution.

   <Zakim> MSM, you wanted to ask about extension

   Michael: Does the the flexibility that we're talking about extend to
   allowing extension mechanisms to provide the functions Mohamed is talking

   Norm: Yes. The constraints on extension are fairly limited.

   <scribe> ACTION: Norm to clarify resolution of URIs in the spec [recorded
   in http://www.w3.org/2007/07/19-xproc-minutes.html#action01[9]]

   Mohamed: I just want to be sure, I felt that XProc was trying to resolve
   this part of XSLT problem, to make it possible to embed it and orchestrate
   it better.

   Norm: I think we've improved things, we can chain arbitrary steps
   together; we just haven't tried to come between URI resolution and the
   bits you get back. I'm not sure we *can* go there.

  p:make-uris-absolute proposal


   Norm: It's hard to do this any other way; I'm in favor.

   Alex: I'm in favor too
   ... Required or optional?

   Norm: I'm inclined to make steps required unless they're an enormous
   burden to implement.

   Proposal: Required step V1.


  p:add-xml-base-attributes proposal


   Proposal: Required step V1.


  Grouping in p:wrap-sequence


   Norm attempts to ask his question

   Norm: I think all we need to do is make the output a sequence and clarify
   the adjacent stuff.


  Making href optional on p:log proposal


   Alessandro: My understanding is that p:log is intended for debugging; in
   general, when I look at other similar constructs, you don't have to
   specify where the data is going to go.
   ... Usually where the data goes is configured externally. I'd like to be
   able to do that in XProc.

   Norm: Yeah, I can see that.

   Mohamed: Since we say that there's only at most one p:log for each port, I
   think it makes sense.


  Questions about defaulting and syntactic shortcuts


   Norm: I don't really want to do these things, but like I said in the
   message, I don't have grounds to turn them down.

   Alex: I'd like AVTs.

   Norm: One of my input shortcuts clearly doesn't work, I don't think we
   should do any of them.

   Alex: I don't think so either.

   No changes.

  Questions about xsl:message from XSLT


   Norm: I think XSLT messages are a secondary output that you only get a
   hold of if there's an error.

   Alex: I think you're right.

   No changes.

  Issues between here and Last Call:

   Norm: I think base URI handling is handled by the steps we added today.

   Alex: If a document comes out of a step, what's its base URI/

   Norm: I think each step needs to say how it produces the base URIs of the
   documents it produces.

   Mohamed: Do we need a p:base-uri() function?

   Norm: I don't know.
   ... Does anyone else know of something that stands between here and Last

   Alex: Do we have to review our use cases and make sure we've hit them?

   Norm: Have to, I don't know, should we, yes?

   Mohamed: I'll give it a try.

  Any other business?

   So for the agenda next week, I think it'll consist of reviewing the draft
   that Alex and I produce and, if no one raises any issues, voting to take
   it to Last Call.


Summary of Action Items

   [NEW] ACTION: Norm to clarify resolution of URIs in the spec [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/07/19-agenda
   [3] http://www.w3.org/2007/07/19-xproc-irc
   [9] http://www.w3.org/2007/07/19-xproc-minutes.html#action01
   [16] http://www.w3.org/2007/07/19-xproc-minutes.html#action01
   [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.128 (CVS
    $Date: 2007/07/19 16:08:03 $

Received on Thursday, 19 July 2007 16:10:32 UTC