- 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 UTC