XML Processing Model WG

Meeting 142, 30 Apr 2009


See also: IRC log


Norm, Henry, Mohamed, Paul


Accept this agenda?

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


Accept minutes from the previous meeting?

-> 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 2.2.1?

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


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


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 suite.

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 scribe.perl version 1.135 (CVS log)
$Date: 2009/05/06 15:16:46 $