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

XProc Minutes 02/03 November 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 11 Nov 2009 10:52:28 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2vdhhoy83.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/11/02-minutes

[1]W3C

                                   - DRAFT -

                            XML Processing Model WG

02 Nov 2009

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
           Norm, Henry, Vojtech, Mohamed (by phone, in part)

   Regrets
           Paul, Alex

   Chair
           Norm

   Scribe
           Norm

Contents

     * [4]Topics

         1. [5]169 XQuery and statically known namespaces
         2. [6]173 Change p:system-property to return an untyped atomic
         3. [7]175 Subtlety about p:xquery
         4. [8]174 p:instruction-available()
         5. [9]168 A imports B, B imports A
         6. [10]170 Test p:import #006
         7. [11]Test suite coverage
         8. [12]Revisit 169
         9. [13]Review 174
        10. [14]Review 168: circular imports
        11. [15]Review 170: p:import #006
        12. [16]Any other questions about the editor's draft?
        13. [17]Review test suite coverage
        14. [18]Schema validity tests
        15. [19]Processing external subsets

     * [20]Summary of Action Items

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

  169 XQuery and statically known namespaces

   Vojtech: What does p:namespaces mean there?

   Norm: That's clearly just a cut-and-paste error, that can't have any
   meaning.
   ... That leaves "The namespace declarations in-scope for the containing
   element".

   Vojtech: What is that, the p:xquery, the c:query, or something else? What
   about inline vs. external queries?

   Norm: Right.
   ... I see three choices:
   ... 1. We could say it's the p:xquery element
   ... 2. We could say it's the c:query element, or
   ... 3. We could decide this was a mistake and just leave it
   "implementation defined" (per XQuery itself) and say that users have to
   declare new namespaces if htey want to use them in their query.

   Vojtech: I've implemented 2, it's not hard.

   Norm: Looking casually at my code, I seem to have implemented 3.
   ... If you have an inline query, it makes some sense to take the
   namespaces declared "above you"
   ... If you have an external query, then either you have to do this:
   ... <c:query xmlns:foo="[21]http://...">for $f in //foo:bar...
   ... or this: <c:query>declare namespace foo="[22]http://..."; for $f in
   //foo:bar...

   There's not a lot of value in taking them from the query in the external
   case.

   Vojtech: What about conflicts, if you have something from the environment
   that's declare differently by the query

   Norm: I think XQuery says that the ones explicitly declared win, but
   whatever it says, that problem already exists.
   ... I'm inclined to say that using the bindings on p:xquery is the right
   thing. Or saying you don't get any at all.
   ... What about the case where the p:xquery step is in a p:for-each. If the
   bindings come from the c:query element, then potentially the static
   context has to be reinitialized for each iteration of the loop.
   ... I think right now you can instantiate the step and its static context
   once and use it over and over again. I think that's a good thing.

   Vojtech: If we say that the bindings on the p:xquery would be used, it
   would be the first time we've done that in XProc. No other step behaves
   that way.

   Norm: Well. Yes and know, those are used for things like shortcut options.

   We can come back to this when Henry arrives.

  173 Change p:system-property to return an untyped atomic

   Norm: Nevermind, this no longer makes any sense given the changes we made
   to the p:version system property.
   ... Now I'll use p:version-available or construct a string based test of
   the p:version system property.

  175 Subtlety about p:xquery

   Norm: On closer examination, this is editorial. And yes, Florent is right.

   Instruct the editor to fix it.

  174 p:instruction-available()

   Norm: I think that version-available is sufficient granularity.

   Vojtech: Would this work for things in other namespaces?

   Norm: Maybe, but we don't really let you put in your own stuff in
   arbitrary places.

   Vojtech: Use-when is going to get used for other things.

   Norm: A new function can be added in a later version, if a new class of
   these things really develops. The current non-step elements are pretty
   random, they don't form any sort of meaningful class in my mind.

   Proposal: For V1.0, version tests are sufficiently granular. Keep the
   status quo.

   Vojtech: What about testing for serialization options: is XML 1.1
   available?

   Norm: Yeah.

   Vojtech: I think the function would be really complicated.

   Norm: For V1.0 can we live with testing vendor strings?
   ... It seems like an area that might be useful some day, but I'm not sure
   I want to add a whole raft of functions just to test serialization
   options.

  168 A imports B, B imports A

   Vojtech: We say that circular imports are not allowed, but we describe how
   to deal with it.

   Henry notes that it seems odd to forbid them.

   Norm: I think we thought it would be an error, but in the light of
   re-entrancy, it probably shouldn't be.
   ... It matters in XSLT because XSLT allows multiple definitions of the
   same thing. They get sorted in "import priority" order.
   ... So if XSLT allowed circularity, they'd never bottom out.
   ... We don't allow redefinition of the same step types, so I think we can
   allow circularity as a special case of re-entrancy.

   Vojtech: So remove the static error.

   Norm: Yes.

  170 Test p:import #006

   Norm: I have mixed feelings about this one, but I think the answer is
   probably correct.
   ... I wrote the spec the way I did because it wasn't clear that
   implementations would be able to tell.
   ... But in fact, they have to for things like XInclude, so maybe we've
   already crossed this bridge.

  Test suite coverage

   Vojtech: I think we're still missing some tests for validation steps.
   ... And I don't think we have tests for all the http-request options
   (multipart bodies and such)

   Norm: (reviewing the coverage report) We're in remarkably good shape

   Reviewing items from this morning.

  Revisit 169

   Norm summarizes the decision to use in-scope namespaces from the p:xquery
   element

   Mohamed: I would prefer to say that "text" input formats don't inherit
   anything from the XML that contains them.

   Norm: I can certainly live with that, I was going for a small change
   rather than a big one.

   Henry: I like the consistency of saying namespaces only inherit in XML. So
   namespaces don't inherit into text formats.

   Norm: I like it too.

   Proposal: In p:xquery, change the "Statically known namespaces" to
   "unchanged".

   Accepted.

  Review 174

   Henry: He's asking for granularity that no other spec provides.

   Mohamed: Is an implementation able to provide specific functions in the
   static context for use-when?

   Norm: 2.7.10 says you can

   Vojtech: But you can't use them in use-when

   Norm: Well, maybe you can, if you can use a group to wrap the test with
   some test that doesn't use them.

   Mohamed: And you can have your own system properties, as long as they
   aren't in the p: namespace?

   Norm: Yes.

   Vojtech: It would be nice if the spec was clearer on this point.

   Norm: Yes, it should say that implementations are forbidden from adding
   new system properties in the p: namespace, but may add ones in other
   namespaces.

  Review 168: circular imports

   Proposal: Remove the prohibition on circular imports, they're just a
   special case of re-entrancy.

   Accepted.

  Review 170: p:import #006

   Norm: I was worried that the information might not be available, but you
   really already need it for XInclude and other things.

   Proposal: The test is correct, update the spec.

   Accepted.

  Any other questions about the editor's draft?

   Some discussion of the arrangement of the various schemas with respect to
   attributes and types.

   Norm: Are we finished?

   No dissent voiced.

   Norm: We have to go back to Last Call, but there's precedent for going
   directly from LC to PR. I think we should plan to do that.

   General support for that proposition.

   Norm: When does the publishing moratorium end?

   Henry: Requests to publish can begin again on Monday, 9 Nov.

   Norm: Ok, so I'll plan on a date of perhaps 11 Nov.
   ... What's the minimum length for a LC?

   Henry: Three weeks.

   Ok. So if we publish on 11 Nov, we can end on 2 Dec?

   Henry: Yes.

   Norm: Ok, we can, potentially pass a motion to go to PR on 3 Dec.

   Proposal: The editor to implement the decisions made today and request a
   new LC draft be published on 11 Nov with a 3 week LC ending on 2 Dec.

   Accepted.

  Review test suite coverage

   -> [23]http://tests.xproc.org/testsuite/coverage.html

   Returning for a moment to the question of teh version attribute, required
   or default to 1.0?

   Henry: Two precedents: XSLT, where it's required, and everyone hates it.
   ... but people have gotten used to it.
   ... And XML where it was a huge mistake to require XML 1.1 documents to
   have an explicit version number.
   ... I expect the language to be backwards compatible. I don't wish it to
   be the case that my pipelines simply stop running becuase 10 years from
   now people write processors that are only V2.0 and upwards supporting.
   ... I'm happy for it to run in whatever the current version is.

   Norm: Right. So this is an argument for no version numbers at all.

   Mohamed: I think there are two levels: we already agreed that we need
   version to declare what version it is.
   ... I think what Henry is asking for is some sort of default strategy. If
   you don't mandate to have a version, then the question is what is the
   default version?
   ... What I hear Henry asking for is that the default be the
   implementations "current" version.

   Norm: I'm coming around to Henry's way of thinking.

   Mohamed: Yes, and you could request the version you wanted explicitly on
   the command line if the processor supports it.

   Vojtech: Before it was hard to see what versions of XProc were supported.
   That's easier now with the new functions.

   Norm: I see. So why would you want to put a version on a pipeline if the
   pipeline can dynamically change its behavior based on the version.
   ... That's pretty compelling to me.

   Mohamed: One argument in favor of keeping version is that it's easy to add
   when you're cutting and pasting.

   Norm: So an existing V1 pipeline grows a V2 feature, it's fed back to a V1
   processor and that processor falls over.
   ... Either you have to add a version attribute or you have to use use-when
   to simplify the pipeline for the V1 processor.
   ... The alternative is the same, you just forced to do the version story
   even when you don't have to.

   Henry: The anti-version indicator camp say that version indicators create
   walled gardens. And also that they're a disincentive for people to get
   into the market.
   ... So the question is, what are the semantics. I'm happy with an advisory
   semantics. I put them in to document what I meant.
   ... I wrote this document against this version of this spec. It's helpful
   to authoring tools to know that.
   ... That's not the kind of semantics that we're looking at here. Or that
   XSLT have used.
   ... We have these notions of compatibility modes.
   ... So either version identifiers are author metadata or
   implementation-driving compatibility modes.
   ... In the former case, it doesn't make sense to make them required.
   ... In the latter case, there I don't know which makes more sense.

   Norm: I'm conflicted. I've come to prefer not requiring them, but the one
   concrete example I can think of is that requirement them improves
   interoperability.

   Henry: Schema says that they expect 1.0 schemas to be conformant 1.1
   schemas. The vast majority of schema documents conformant to 1.1 should
   also conform to 1.0 leaving aside the new things.
   ... And where they are compatible, the semantics will be the same.
   ... Schema provides use-when semantics with vc:

   <JeniT> Hi :)

   Henry: Where they appear, minVersion and maxVersion are compared to *the
   version* supported by the processor.
   ... So, if you don't use minVersion and maxVersion then the semantics of
   anything from previous versions will not have changed.
   ... That's the contract that Schema have implicitly agreed to.
   ... With the schema constructs, I don't think there is any way to produce
   a backwards compatibility mode, so maybe this wasn't a useful analogy.
   ... Another way to come at this: does our definition give us any response
   to the people who say "version indicators require you to implement the
   history of the world".
   ... I think we need to be clear that a V2 processor that sees a V1
   pipeline can run it as long as it knows that it doesn't use anything
   that's incompatible with it's implementation.
   ... You don't have to implement all the preceding versions, just tell if
   you can run them.
   ... You only have to look at the pipeline if you know there's been a
   change or reduction in functionality from that version.
   ... So the cost of saying that a pipeline is a "1.0" pipeline is nearly
   zero.

   Bah. Stupid hotel internet timed me out.

   <JeniT> I'm still here, but also doing useful things.

   Cool.

   Any thoughts on the straw poll?

   <JeniT> I didn't see a straw poll

   Just a few lines back up in your buffer?

   Let's do a straw poll quickly before lunch:

   [13:03] <Norm> 1 = version is required

   [13:03] <Norm> 2 = version is not required, defaults go 1.0

   [13:03] <Norm> 3 = version is not required, defaults to implementation
   defined

   [13:04] * Norm nods to jeni, think about your answer :-) I'll get you last

   [13:04] <Norm> Norm: 1

   [13:04] <Norm> Henry: 1

   [13:05] <Norm> ...The only one I can't live with is 2.

   [13:05] <Norm> Vojtech: 3

   [13:05] <Norm> And you, JeniT ?

   <JeniT> Pfff

   <JeniT> I can live with 1 or 3

   ok.

   <JeniT> The stringent wording in the backwards compatibility section makes
   me err towards 3

   Yeah. Ok. So here's the rub as I see it.

   If you don't specify the version, everyone is happy with the changing
   versions until an interoperability problem arises

   We both work with 1.0 processors...

   You get a 2.0 processor...

   You start using 2.0 features...

   Eventually you send me your pipeline and it's rejected immediately becuase
   I have only a 1.0 processor.

   At this point one of us has to add "version='2.0'" to it.

   (Let's assume that's enough to make it work, the cases where you also need
   use-when are even harder to justify)

   But if you'd been forced to use it earlier, it'd been inconvenient for
   you, but then interoperability would have worked better.

   So I'm really torn.

   <JeniT> Yes, me too :)

   Of course, if you think everyone is going to have to use use-when anyway,
   then what version you put on the thing is irrelevant and 3 is better.

   So, we're all in agreement. We're all torn :-)

   <JeniT> I think it partly depends on what you think is going to happen in
   the future.

   Indeed.

   <JeniT> ie how likely it is that future versions are going to change
   things in backwards-incompatible ways

   wb ht

   Well. Most steps are probably never going to change in a
   backwards-incompatible way.

   OTOH, I won't be surprised if p:xslt grows a "messages" port, and for that
   you'll need "version='2.0'" to get a 1.0 processor to do the right thing.

   So it's really the forwards-compatible changes that are the issue, I
   think.

   <JeniT> So my inclination is that if we're torn, we shouldn't require the
   version: it becomes a best practices decision that individual developers
   can make depending on their situation.

   Hmm.

   Ok. I can live with that. I think we're going to try to shop it around to
   a few of the other TPAC folks and see if we get any compelling feedback.

   <JeniT> Requiring the version is us saying "it will be good for you in the
   long run if you always put a version on the pipeline"

   <JeniT> OK

   Thanks for taking the time!

   Now Vojtech and I are going to try to get the test suite up to 100%

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

   Date: 3 Nov 2009

  Schema validity tests

   Norm: I've confirmed that SaxonSA will support setting strict and lax.
   ... Henry, can you write a couple of simple schema tests that will
   demonstrate use of strict vs. lax?

   Henry: Yes

  Processing external subsets

   Some discussion of p:document; the spec currently says "The external
   subset should not be processed, but some parsers do not provide that
   option."

   Is that really what we want? Should we delete that sentence? Should we
   change that to "should"?

   Further discussion reveals that p:document must be wrong in this regard
   since if you don't expand entities you can't perform XPath on the
   resulting documents.

Summary of Action Items

   [End of minutes]

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

    Minutes formatted by David Booth's [24]scribe.perl version 1.133 ([25]CVS
    log)
    $Date: 2009/11/11 15:47:27 $

References

   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/11/02-agenda
   3. http://www.w3.org/2009/11/02-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/11/02-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/11/02-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/11/02-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/11/02-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/11/02-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/11/02-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/11/02-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/11/02-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/11/02-minutes#item08
  13. http://www.w3.org/XML/XProc/2009/11/02-minutes#item09
  14. http://www.w3.org/XML/XProc/2009/11/02-minutes#item10
  15. http://www.w3.org/XML/XProc/2009/11/02-minutes#item11
  16. http://www.w3.org/XML/XProc/2009/11/02-minutes#item12
  17. http://www.w3.org/XML/XProc/2009/11/02-minutes#item13
  18. http://www.w3.org/XML/XProc/2009/11/02-minutes#item14
  19. http://www.w3.org/XML/XProc/2009/11/02-minutes#item15
  20. http://www.w3.org/XML/XProc/2009/11/02-minutes#ActionSummary
  21. http://www.w3.org/XML/XProc/2009/11/http:/...
  22. http://www.w3.org/XML/XProc/2009/11/http:/...
  23. http://tests.xproc.org/testsuite/coverage.html
  24. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  25. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 11 November 2009 15:53:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 11 November 2009 15:53:20 GMT