See also: IRC log
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?
... 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="http://...">for $f in //foo:bar...
... or this: <c:query>declare namespace foo="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.
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.
Norm: On closer examination, this is editorial. And yes, Florent is right.
Instruct the editor to fix it.
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?
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.
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: 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.
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.
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".
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?
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.
Proposal: Remove the prohibition on circular imports, they're just a special case of re-entrancy.
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.
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?
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.
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.
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> I can live with 1 or 3
<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.
<JeniT> ie how likely it is that future versions are going to change things in backwards-incompatible ways
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.
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"
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
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?
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.