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

XProc Minutes 30 Apr 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 06 May 2009 11:18:36 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2k54up8dv.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/04/30-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 142, 30 Apr 2009


   See also: [3]IRC log


           Norm, Henry, Mohamed, Paul





     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 7 May 2009
         4. [8]103 p:validate-with-xml-schema - multiple schemas
         5. [9]124 XQuery 1.0
         6. [10]127 rejecting invalid/unsupported p:serialization options
         7. [11]128: default namespaces
         8. [12]Next steps
         9. [13]Default processing model.
        10. [14]Any other business?

     * [15]Summary of Action Items


  Accept this agenda?

   -> [16]http://www.w3.org/XML/XProc/2009/04/30-agenda


  Accept minutes from the previous meeting?

   -> [17]http://www.w3.org/XML/XProc/2009/04/23-minutes


  Next meeting: telcon 7 May 2009

   No regrets given.

  103 p:validate-with-xml-schema - multiple schemas

   Norm: We have a partial resolution, I propose that we leave the rest
   implementation dependant.

   MoZ: Why implementation-dependent?

   Norm: Uhhh...

   Henry: Because it will depend on what the underlying validator will do.

   Norm: And because in 2.2.1 we say implementation-dependent mostly.
   ... Anyone think we can answer 103 normatively w/o making changes to

   None heard

   Proposal: The behavior is implementation-dependent.


  124 XQuery 1.0

   Norm summarizes the email

   Norm: In short, I want to take the version numbers out and say that the
   p:xquery step (for example) does XQuery, the exact versions of which being

   MoZ: I'm concerned because it opens an interoperability problem. We
   explicitly solved this problem for XSLT.

   Henry: Yeah, but most W3C specs are moving in this direction. In general,
   it seems to me that it's an overall improvement to the value proposition
   for our users if as many tools as possible support as many versions as

   Norm: Right. In particular, I want to avoid making an impl non-conformant
   just because a new version of XQuery comes out.

   Henry: I shouldn't have said version, because I've been falling into the
   habit of assuming everyone will follow the rules.
   ... I'm happy to say "this or subsequent editions" on the assumption that
   there will be backwards compatibility.

   Norm: So you do want to make an XProc impl non-conformant if it supports
   XQuery 1.1 or 2.0?

   Henry: I don't want an implementation that only supports XQuery 2.0.
   ... And if I want to be careful, I have to go further and say only an
   XQuery 2.0 that's not backwards compatible with 1.0.

   MoZ: Can we say XQuery 1.0 or subsequent edition or version that is
   backwards compatible with 1.0.

   Norm: I guess I could live with that.

   Henry: I was going to add one more bit of flexibility: as well as other
   non-backwards compatible versions at user option.
   ... The point is, you must support something that's backward compatible
   with what we spec, but you can do other things if you give the user

   MoZ: I like it, and I think we should say the same thing for

   Norm: Fine by me.

   MoZ: What is the expect behavior for XML Schema?
   ... If the processor only handles 1.1 and not 1.0, is it something we want
   to avoid or allow?

   Norm: Should we say the same thing for XML Schema?

   Henry: I'd even think we could go so far as to say this once in the the

   Norm: I'm ok with that.

   Proposal: steps must implement the specified version or any subsequent
   edition or version that is backwards compatible. At user option, they may
   support other, non-compatible versions or extensions.


  127 rejecting invalid/unsupported p:serialization options

   Norm summarizes.

   Norm: I think it boils down to saying that an implementation MAY or MUST
   or MUST NOT check serialization options even if it's not serializing.

   MoZ: I think MAY is sensible.

   Norm: I think that's probably right. It's a small interop problem, but
   only on pipelines that aren't, in some sense, correct.

   Proposal: Use MAY


  128: default namespaces

   Norm summrizes.

   MoZ: For elements, it's explicit in XPath 1.0; for function calls it's in
   ... We definitely have to note it.

   Norm: I think we should say that element names w/o a prefix are in no
   namespace, function names w/o a prefix always invoke the underlying XPath
   functions. They are not effected by any in-scope binding for the default

   MoZ: I think that for 2.0, it's already said in the spec. It's only when
   you're in 1.0 when you have to say that.

   Norm: The other part is, in an XPath 2.0 implentation, we don't provide
   any mechnaims for change the default function namespace.


   Norm: We have closed all of the outstanding comments on XProc!

  Next steps

   1. The default processing model

   2. Get to PR!

   3. A complete test suite

   4. We've missed our heartbeat requirement

   Norm: Proposal: we publish a new CR draft, containing all of the
   resolutions sometime in May then work on finishing the test suite while we
   talk about the default processing model.

   Paul: We're not going to CR again?

   Norm: No, we're not.

   Henry: It's going to be published as CR in TR space.

   Norm: Anyone think that's a bad plan?

   MoZ: I think it's a good plan.
   ... We need to say that we're moving forward.
   ... We'll have a chance to encourage people to help us with the test

  Default processing model.

   Not ready for discussion this week

  Any other business?

   None heard.


Summary of Action Items

   [End of minutes]


    Minutes formatted by David Booth's [18]scribe.perl version 1.135 ([19]CVS
    $Date: 2009/05/06 15:16:46 $


   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/04/30-agenda
   3. http://www.w3.org/2009/04/30-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/04/30-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/04/30-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/04/30-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/04/30-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/04/30-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/04/30-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/04/30-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/04/30-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/04/30-minutes#item08
  13. http://www.w3.org/XML/XProc/2009/04/30-minutes#item09
  14. http://www.w3.org/XML/XProc/2009/04/30-minutes#item10
  15. http://www.w3.org/XML/XProc/2009/04/30-minutes#ActionSummary
  16. http://www.w3.org/XML/XProc/2009/04/30-agenda
  17. http://www.w3.org/XML/XProc/2009/04/23-minutes
  18. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  19. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 6 May 2009 15:33:12 UTC

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