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

XProc Minutes 30 Aug 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 30 Aug 2007 12:25:52 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2hcmhat0v.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/30-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 81, 30 Aug 2007


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 6 September 2007
         4. Charter extension :-(
         5. Meeting at the W3C Technical Plenary
         6. Comments on the new draft
         7. p:pack
         8. Type attribute on p:option, etc.
         9. Namespace fixup
        10. Error numbers
        11. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/08/30-agenda

   Add: splitting the spec?


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/08/23-minutes


  Next meeting: telcon 6 September 2007

   No regrets given.

  Charter extension :-(

   Norm: Henry, what do we need to do?

   Henry: I'm not sure, but as a tactical matter let's wait until we get to
   Last Call before we do it.

  Meeting at the W3C Technical Plenary

   Norm: We should plan to meet at the plenary, Th/Fr 8/9 Nov 2007 in
   Cambridge, MA, US
   ... I've requested a projector, a whiteboard, and a phone

   Norm will be there

   Henry will be there in part

   Paul will be in the hotel, but at the XSL FO meeting

  Comments on the new draft

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

   Henry: Woo hoo! seems appropriate

   Norm: Did anyone look at Henry's editorial changes

   Mohamed: I did and I think it addressed many issues.
   ... I think some of the type stuff isn't in the spec (options that must be
   QNames, etc.)

   Henry: I think that stuff is in 3.9

   Mohamed: Yes, that's ok. But I think some of it is missing in required

   Henry: At the moment, the changes in section 7 are only visible in the
   copy attached to the email that I sent

   Mohamed: Ok, maybe I was looking in the wrong place.

   Henry: I've been trying to make the steps more regular (editorially).
   ... Alex had evolved towards a standard way, but they hadn't all been

   Norm regrets Alex's absence.

   Henry summarizes his editorial changes.

   Norm: I think we should accepted Henry's changes.

   Norm and Henry will work together on the draft.

   Mohamed: I'm very happy with the styling changes in the tableaus

   Norm: Yeah, I think it worked out pretty well too, though I'm open to
   suggestions for more improvements.




   Mohamed: We're only missing a few things, most of which we can get with
   ... An option on p:count would allow it to return 0, 1, or more instead of
   counting all of them
   ... Adding an option on split-sequence to stop after first false, that
   could be an option too.
   ... And p:pack
   ... I'm not sure I want all of them, but I was trying to see what we
   couldn't do.
   ... Some of them would require p:input="*" and p:output="*".
   ... But the three named above could be done pretty easily.

   Norm: I'm sort of inclined leave these until the next release or as exproc
   ... What do folks think of a 0, 1, or more sort of step as an
   alternative/option to p:count?

   Henry: I'm not sure how central the requirement for this is?
   ... I appreciate that there's an in principle need, but what is the
   real-world use case?

   Norm: I'm not hearing a lot of support

   No consensus to add this.

   Norm: What about a variation on p:split-sequence to stop after the first

   Henry: Same question

   Norm: I'm not hearing a lot of support for this either

   No consensus to add this.

   Henry: I think it will be very reasonable during CR to respond to requests
   of the form "please add a step such as..." with some optional step that we
   might eventually make required.

   Norm: That leaves us with p:pack

   Mohamed: The use case for this one is to make a comparison of two
   sequences of documents.

   Norm: I see, so instead of having two sequences, you can just take the
   first two and then the next two, etc.

   Mohamed: You get the two documents in a single wrapper

   <MoZ> <A><a/><b/></A>

   Norm: Right.

   Henry: I'm still not clear; if I have four documents on each input port,
   how many do I get?

   Mohamed: You get four output documents; each of which contains a wrapper
   that has two documents.

   Henry: I think this probably is a good idea.
   ... It's the dual of split-sequence to some extent and it matches a unix
   utility that I use occasionally

   Norm: Anyone object to adding p:pack?

   None heard; accepted.

  Type attribute on p:option, etc.

   Norm: There's been some discussion in email.

   Proposal: Add a type attribute on p:option?

   No support heard, at least one object; proposal fails.

  Namespace fixup

   Scribe interrupted by FedEx

   Henry: At the beginning of 2.2, we say that it's XML that flows between
   ... There is no statement here which says that the XML must be
   serializable as an XML document.

   Richard: I don't think that's what we should be saying.

   Henry: As it stands, as an implementor, I don't think I'd have any
   obligation to throw an error if a step produced as output an
   unserializable document information item.
   ... e.g., I am XML 1.0 based implementation and you give me a document
   which has two elements with an undeclared namespace.

   <root xmlns="foo"><child xmlns=""/></root>

   You can't do that in XML 1.0

   (That example doesn't actually work, but hopefully the idea is clear)

   Henry: The problem arose in p:add-attribute. Do we require namespace
   fixup? That is, should we say that the output document contains an
   in-scope namespace binding for the prefix used in the attribute if there
   isn't one already.

   Richard: It seems that on the individual questions of what steps should
   do, we should say.

   Henry: I think that's a question we should put to the WG.

   <MoZ> <p:root xmlns:p="foo"><p:child xmlns:p=""/></p:root> is impossible
   in XML 1.0 but we just have to change the prefix !

   Richard: As to the general question, we say that the things that flow
   between the steps are XML documents. So if you attempt to pass an
   unserializeable infoset, that's clearly an error.
   ... I think this should be partitioned between a general statement like
   that statements about the individual steps.

   Henry: I think there's a finer granularity that's worth considering.
   ... There are at least two senses of serializable:
   ... Given a fairly close transcription of the infoset, one possible
   reading of "serializable" is, if you express every property in your object
   model, the result will be a WF XML document.
   ... The next step is to say, no, that's too weak, the sensible meaning is
   that with the addition of namespace bindings and possibly additional
   prefixes, the document could be serialized successfully.

   Richard: I'd say that the definition is that there's a textual XML
   document that has the same infoset.
   ... If we wished to allow some latitude on that then the components
   themselves should say what the latitude is.

   Henry: I think that means: in one case the spec says, if serialization is
   called for then it must be possible with namespace bindings synthesized as
   ... The other alternative is to say that that must obtain at every
   transition between steps.

   Richard: I would be happy to allow implementations the latitude of not
   fixing up namespaces until they actually serialized the output.
   ... But that should be considered an optimization
   ... Each step should say that it works as if such a document was possible
   at every transition

   Henry: So this means describing namespace fixup for at least all ten of
   these steps
   ... I'm happy to do that, but it seems overkill.

   Richard: I'd abstract the problem and write a single paragraph that says

   Norm: Anyone disagree with the strict reading of serialization between

   Henry: Yes, I think this is an unbearable burden on implementors.

   Richard: Where do errors occur if you don't?

   Henry: Given that we have an XSLT 1.0 step, it's clear that this can be
   ... All you have to do is do add attribute and then check the namespace
   bindings with XSLT.
   ... It's definitely detectable.

   Richard: I'm not against it being an allowed optimization to do this, the
   thing that I want is that the spec be written as if every step produced
   and consumed textual XML and anything else is an optimization.

   Some discussion about what 2.2 meant.

   Henry: I'm happy to reword this paragraph but I think we need to do it
   with our eyes open.

   Mohamed: I object to the idea that we put this burden on implementors too.

   Norm: Let's take this to email

   Richard: I think the minimum position is that steps be allowed to
   serialize between every step and be allowed to produce an error if they

  Error numbers

   No value in fiddling with the error numbers and non-zero chance of screw

  Any other business?



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/08/30-agenda
   [3] http://www.w3.org/2007/08/30-xproc-irc
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0080.html
   [8] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0101.html
   [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.128 (CVS
    $Date: 2007/08/30 16:18:24 $

Received on Thursday, 30 August 2007 16:26:07 UTC

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