See also: IRC log
-> http://www.w3.org/XML/XProc/2009/04/30-agenda
Accepted
-> http://www.w3.org/XML/XProc/2009/04/23-minutes
Accepted
No regrets given.
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 2.2.1?
None heard
Proposal: The behavior is implementation-dependent.
Accepted.
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 implementation-defined.
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 possible.
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 control.
MoZ: I like it, and I think we should say the same thing for p:xsl-formatter.
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 document.
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.
Accepted.
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
Accepted.
Norm summrizes.
MoZ: For elements, it's explicit
in XPath 1.0; for function calls it's in XSLT.
... 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 namespace.
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.
Accepted.
Norm: We have closed all of the outstanding comments on XProc!
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 suite.
Not ready for discussion this week
None heard.
Adjourned.