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

XProc Minutes 18 Dec 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 07 Jan 2009 10:24:58 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2bpujf8ad.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/12/18-minutes

[Sorry for the delay]


                                   - DRAFT -

                            XML Processing Model WG

Meeting 132, 18 Dec 2008


   See also: [3]IRC log


           Norm, Mohamed, Vojtech, Henry

           Andrew, Paul




     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 8 Jan 2009?
         4. [8]Review CR comments
         5. [9]006
         6. [10]005
         7. [11]Any other business?

     * [12]Summary of Action Items


  Accept this agenda?

   -> [13]http://www.w3.org/XML/XProc/2008/12/18-agenda


  Accept minutes from the previous meeting?

   -> [14]http://www.w3.org/XML/XProc/2008/12/11-minutes


  Next meeting: telcon 8 Jan 2009?

   Norm gives regrets for 15 Jan, Henry to chair.

  Review CR comments

   -> [15]http://www.w3.org/XML/XProc/2008/11/cr-comments/

   The first issue is 004, preserving base URI

   Henry summarizes his mail. The net net is: "This means the spec. might be
   construed to have an interop problem, wrt processors which serialise
   between each step and those which don't."

   Henry: We say in the spec that it isn't non-conforming to do fixup between
   each step.

   Norm: I think we need to decide if we want to base the technical decision
   on avoiding the interop problem.

   Henry: Why doesn't this problem arise for namespace decls? Because we
   don't promise that ignored prefixes actually remove namespace bindings.
   They come back if they're needed.
   ... I don't know if that's relevant parallel or not.

   Vojtech: What is the use case?

   Norm: It's 5.11


   Norm explains the rationale for the use case.

   Some discussion. It turns out that performing steps 1, 4, 2, 3 would give
   the same result but would not require base URIs to be preserved after
   xml:base attributes are deleted.

   Henry: Because we require base URIs to be preserved,
   serialize-between-steps implementations will have to add xml:base
   ... That means serialize everywhere processors will produce xml:base
   attributes where other processors won't.

   Mohamed: You need to put it in some namespace or something because
   xml:base won't work for all the cases. Because we have to keep infoset and
   PSVI information, you might need to have an XML document that couldn't be
   used directly.
   ... You might have to serialize with some special intermediate form in
   order to preserve all the properties.

   Norm: I suppose we could change the MUST on base URI to SHOULD.

   Henry: That will definitely introduce interoperability problems.

   Norm: I'm torn. I favor the interpretation that says removing xml:base
   doesn't change the base URI in the infoset, but I concede that that may be
   difficult for some implementations.

   Vojtech: I just don't understand why removing the xml:base attribute
   doesn't change the underlying base URI property.

   More discussion.

   Mohamed: One other spec could give a sort-of answer, and that's XQuery

   Norm: We need an answer...

   Henry: I'd like to think about it a little longer, and I'd also like to
   have Richard involved.

   Norm: Ok, I guess we can put it off until 8 Jan.

   Vojtech: If we combine Norm's approach with Mohamed's suggestion, then
   it's doable even for processors that serialize between steps.

   Henry: Yes, I think I'm leaning that way too, but I'd like to think about
   it some more.

   Norm: Ok, we'll come back to this on 8 Jan.

   Vojtech: We have other steps that can modify attributes, we should clarify
   their semantics as well.

   Norm: Yes.
   ... There's add-attribute, set-attributes, and string-replace


   Norm: I think we can close this one.



   Vojtech: There's a static error for except-prefixes on p:namespaces, I
   think there should say the same for exclude-inline-prefixes

   Norm: Can we use the same error?

   Vojtech: I think so, but we'll have to say something about #default and

   Norm: How about we leave it to the editor, with instructions to use the
   same one if it's practical.

   Henry: Fine with me.

   Vojtech: I also raised a related issue in 027.
   ... Should the unused namespace appear or not?

   Henry: I think the reality is that serializers differ on this point, and
   there's no right answer.
   ... Both answers are right.

   Norm: Do we agree that both are equally correct?

   Mohamed: I don't agree. I think most processors do output the namespace
   even if it's unused.

   Henry: You're right. I think I was wrong. There might be a QName in
   content that does need that prefix.

   Vojtech: In the context of a pipeline, there are often extra prefixes.

   Norm: I think Mohamed is right, the namespace binding is in scope and
   should appear on the result.


   Proposed: The serializer must retain all in-scope namespaces whether they
   are used in XML element or attribute names or not.


   Let's look at 003.

   Norm explains the issue.

   Norm: I think we have resolution on this, but we never discussed it in the

   Proposal: You do have to make the declarations visible in every pipeline.


   Let's look at 002

   Vojtech: You must always specify an empty binding for a parameter input
   port if you don't have one.
   ... And even if you specify a number of p:with-param's then you still have
   to provide the binding.
   ... This all seems very inconvenient.


   Norm: Yeah.

   Vojtech: If you specify p:with-param, you still get the default binding
   which could be confusing.

   Norm draws attention to the parallel with p:with-option and use of p:empty
   to make the binding explicitly empty.

   Mohamed: I think parameters are complicated, but we've made careful
   choices. I think the decisions we've made put the burden on the
   implementor, which is where they should be.
   ... Authors will make mistakes, but they'll learn this one quickly.
   Turning this around might make things even more difficult for the author
   who won't detect the errors until much later.

   Norm: I think if we're going to change this, we'd need a detailed change
   proposal for the spec that covered all the cases.
   ... We might also have to go back to last call if we made these changes.

   Vojtech: I can live with the status quo, but it's obviously confusing as
   the xproc-dev list shows.

   Mohamed: I think we need to make it clear that writing a pipeline with
   parameters requires some care.

   Norm: Does anyone want to persue making a change in this area?

   None heard.

   Proposal: Leave the status quo.


   Issue 001

   Vojtech: We could also have a general error for "document is not a valid
   XProc instance"

   Norm: Vojtech makes a good point about the number of possible errors that
   we might need.

   Some discussion of 16, 38, and 44.

   Norm: I agree that 16 is no longer necessary, it's covered by 38.
   ... I propose that we close 001 by removing error 16 in favor of 38 and
   leaving the more general quesiton until we have more evidence about it.

   Vojtech: I'm fine.

   Mohamed: Agreed.


  Any other business?

   Mohamed: For next time, could we begin to discuss the processing model?

   Norm: Yep. We need to start doing that.
   ... We should at least start talking about a requirements document for

   Happy Holidays and Joyeux Noel!


Summary of Action Items

   [End of minutes]


    Minutes formatted by David Booth's [17]scribe.perl version 1.133 ([18]CVS
    $Date: 2009/01/07 15:23:56 $


   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2008/12/18-agenda
   3. http://www.w3.org/2008/12/18-xproc-irc
   4. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#agenda
   5. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item01
   6. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item02
   7. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item03
   8. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item04
   9. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item05
  10. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item06
  11. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#item07
  12. file:///projects/w3c/WWW/XML/XProc/2008/12/18-minutes.html#ActionSummary
  13. http://www.w3.org/XML/XProc/2008/12/18-agenda
  14. http://www.w3.org/XML/XProc/2008/12/11-minutes
  15. http://www.w3.org/XML/XProc/2008/11/cr-comments/
  16. http://www.w3.org/TR/2006/WD-xproc-requirements-20060411/#use-case-make-absolute-urls
  17. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  18. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 7 January 2009 15:25:43 UTC

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