XProc Minutes 26 Apr 2007

See http://www.w3.org/XML/XProc/2007/04/26-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 65, 26 Apr 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Paul, Norm, Mohamed, Alex, Alessandro, Michael, Henry, Richard

   Regrets
           Andrew, Rui

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 3 May 2007
         4. Error vocabulary proposal
         5. Select vs. match in steps
         6. p:error proposal
         7. p:tee proposal
         8. p:string-replace proposal
         9. Any other business
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/04/26-agenda.html

   Amended with proposals from Alex, Norm, and Mohamed

  Accept minutes from the previous meeting?

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

   Accepted.

  Next meeting: telcon 3 May 2007

   Rui gives regrets for 3, 10 May.

  Error vocabulary proposal

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0141.html

   Norm: I think I should move name and type down from err:errors to
   err:error.

   Rui: If we have a nested try/catch and the inner catch fails, what will
   the outer catch get?

   <MSM> [what data stream is referred to in the line and column numbers?]

   <rlopes> All of them, maybe?

   Henry: The error in the catch?

   Rui: Yes, in the catch.

   Henry: I think the catch should be transparent to the error and the outer
   try gets the failure as if the had occurred directly inside it.

   MSM, The line/column are whatever the step thinks is helpful.

   MoZ: So the first error is lost and the outer catch gets the errors from
   the inner catch.

   <rlopes> yes, that's what I was thinking

   Norm: I suppose we could say that all the errors are propagated upwards,
   but for V1, I'd rather not.

   MoZ: Ok.

   <MSM> [MSM meditates on the utility of an XSLT processor (for example)
   giving two locations (in input, in stylesheet)]

   Norm: Is everyone happy enough to put this in the next spec?

   MoZ: Does #error contain a single document or a sequence?

   Norm: A single document, I think.

   MoZ: But the document may contain multiple error elements.

   <MSM> [MSM then wonders whether location info should be in a p:loc child
   of p:error, rather than in attributes ... or perhaps that's just too
   complicated?]

   Norm: Yes.

   Michael: Do we want to consider allowing a step to provide multiple
   locations?

   Henry: Maybe an alternative way would be to allow the error element to
   contain error elements.

   Michael: It's not forbidden, so we could allow it.

   Henry: I think most of the XML vocabularies do use attributes for this.

   MoZ: For the location, if we are doing some streaming, it's not obvious
   that the SAX API give the location every time.

   Norm: I think the location information is optional; not all steps will
   always be able to give it.

   MoZ: That's why I was supporting MSM, so that we could have an other
   mechanism to identify the location.

   MSM: There's nothing that prevents you from putting a different location
   in the content of the error.
   ... If you have a specialized way of identifying a location, that's OK, we
   just don't expect the framework to understand it.
   ... Having thought about it now for a few minutes, I think this is
   probably OK.

   <MoZ> +1

   Norm: I guess what I'd like to suggest is that we go with this for the
   next draft and see if real world experience makes us want to change it.

   <MSM> [p:code optional? No - better to require that people define an ERROR
   U000 miscellaneous unknown catastrophe]

   MSM: We have href/line/column optional, but is code really supposed to be
   optional?

   Norm: I think for components that don't have defined errors, there's no
   point insisting on a bogus error code.

   Accepted, as amended above.

  Select vs. match in steps

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0137.html

   Henry: Why is it only the outer match that gets selected in:

   <ht>
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0142.html[8]

   Norm: Consistency with p:viewport.

   Henry: In the p:viewport case, there's nothing there to match, that's why.
   The same is true of delete and replace.
   ... In the rename case, you can continue processing the subtree.
   ... I'd hate to have to write select expressions all over the place when I
   just want to hit all the elements that match a pattern.
   ... In the markup pipeline, all of these components use match semantics
   and no one has ever complained.

   Norm: You could sell me either way.

   Alex: I'm looking at these two renames and I think the select version
   looks really strange.
   ... I'd prefer to use match here.

   <ht> This one surely looks simpler:

   <ht> <p:rename>

   <ht> <p:option name="match" value="@foo"/>

   <ht> <p:option name="name" value="bar"/>

   <ht> </p:rename>

   Henry: I really really really think people are going to want to write
   that.

   Richard: I agree that people will want to write these short things, but
   there are cases that are hard with match; I'd prefer to have both.
   ... The first para of a book, for example.

   <richard> (//p)[1]

   <MoZ> p[not(preceding::p)]

   Norm: You're suggesting that it should use select or match

   Richard: I agree that having both would be extra work, but it would be
   obvious.

   Alex: I could live with both.

   Mohamed: Is there really some matching pattern that we really cannot have
   with match that we can have with select.

   Norm: So I'm hearing a consensus that we want both on some.

   Henry: Yes.
   ... I note that there's a very substantial set of match patterns that's
   easy to stream and select patterns tend to be much harder. I suspect that
   getting interop on the select side is going to be harder.

   Richard: I'm not convinced by that because you can look at a select
   pattern and determine if it's really a match. Then you're in the same
   case.

   Alex: If you're going to worry about the streaming in all these
   components, you can't do it in the general case.
   ... The reality is, are we making it harder for the implementor that can
   only stream in one case.

   Richard: If we had a way of asserting that something was streamable, then
   I'd think Henry has a point. But we don't, so you have to test pattern.

   Alex: You could just say that if you use select, you lose.
   ... People interested in streaming are already interested in a subset of
   XPath.

   <alexmilowski> (really a subset of XProc)

   Alex: I'm in favor of putting both options on all these components.

   <MoZ> +1 for both on some

   <MoZ> agree with Henry's position for delete and replace

   Norm: Only on some?

   MoZ: I think that both makes sense on rename, but for delete and replace,
   I really like the fact that it's the same as viewport.

   Norm: But I think that anything that's true of rename is true of delete.

   <alexmilowski> what about delete //*/@id ?

   MoZ: I'd prefer to be consistent with viewport than with components.

   Alex: I'm not sure I see an inconsistency. They have some similarity to
   viewport, but they're more similar to themselves.

   <MoZ> @id[count(parent::*)=1]

   <MoZ> sorry

   <MoZ> @id[count(parent::*)>1]

   Richard: I didn't understand Alex's example.

   Alex: If I want to delete all ID attributes, there are lots of ways to
   write that as a select or match pattern.
   ... My point is that if we're not putting a huge burden on implementors,
   then it's a question of what authors find easier.
   ... We should make things easier for authors.

   Richard: I feel I should point out that //*/@id is a match pattern. You're
   allowed to write rooted match patterns.
   ... It is slightly tedious to implement delete when you might get back
   lists of nodes that contain descendants.

   Straw poll: Should we allow both select and match patterns on all of the
   microcomponents?

   Yes: 3, No: 3, Abstain: 2

   Norm: I suggest we take this to email and come back to it in a week

   Paul: The last email I saw was Norm proposing which one's use select and
   which one's use match. Why did you abstain?

   Norm: Yeah, I just abstained in the hope it would help get consensus.
   ... We need to get to last call.

   Alex: Can we close some of these issues directly in email, or maybe with
   the W3C voting tool?

   Henry: I think each of these does merit discussion.

  p:error proposal

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0114.html

   Accepted.

  p:tee proposal

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0138.html

   Henry: I like the idea, but I hate the name.
   ... The only thing I would consider as an alternative is to be able to
   annotate any connection with a URI.
   ... This is mostly for debugging. Maybe we should try for something even
   lighter weight.
   ... Adding an optional journal, log, or URI attribute to some elements.

   <MoZ> +1 for henry's proposal, it is a debuging feature and should be
   thought more broadly

   Alex: Any implementor could provide features to do this.

   Norm: Yes, but I don't want it to be an implementation-dependent feature,
   I want to be able to run an unmodified pipeline through my implementation
   and yours and compare the results.

   <MoZ> @p:use-output="..href.."

   <scribe> ACTION: Henry to look at the language and see if a broader
   debugging proposal can be made. [recorded in
   http://www.w3.org/2007/04/26-xproc-minutes.html#action01[11]]

  p:string-replace proposal

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0132.html

   Alex: For attributes it replaces the string value; for elements it should
   replace the descendants, yes?

   Norm: Hmmm. Maybe.

   Henry: Wait. We have to address the case where the delete component ends
   ../text().

   Alex: It deletes all the text nodes.

   Henry: Given that you can write text() at the end of the pattern, whether
   that allows us to clarify the question about the diffrence between
   elements and attributes.

   Norm: I think I want attributes to be treated specially.

   Henry: So we can write .../foo or ../foo/node() for the two cases.

   Alex: If you say text() shouldn't it merge adjacent text nodes.

   Norm: Yes.
   ... Do we have consensus to add string-replace?

   Accepted.

  Any other business

   None.

   Adjourned

Summary of Action Items

   [NEW] ACTION: Henry to look at the language and see if a broader debugging
   proposal can be made. [recorded in
   http://www.w3.org/2007/04/26-xproc-minutes.html#action01[13]]
   **
   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/04/26-agenda.html
   [3] http://www.w3.org/2007/04/26-xproc-irc
   [8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0142.html
   [11] http://www.w3.org/2007/04/26-xproc-minutes.html#action01
   [13] http://www.w3.org/2007/04/26-xproc-minutes.html#action01
   [14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [15] http://dev.w3.org/cvsweb/2002/scribe/
   [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
   [17] http://www.w3.org/XML/XProc/2007/04/26-agenda.html
   [18] http://www.w3.org/2007/04/26-xproc-minutes.html
   [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

    Minutes formatted by David Booth's scribe.perl[14] version 1.128 (CVS
    log[15])
    $Date: 2007/04/26 16:12:45 $