XML Processing Model WG

Meeting 108, 17 Apr 2008


See also: IRC log


Paul, Henry, Alessandro, Norm, Vojtech, Andrew, Mohamed
Rui, Alex, Richard


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/04/17-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/04/10-minutes


Next meeting: telcon 24 April 2008?

Continuing regrets from Rui for 24 Apr. No other regrets given.

Consideration of the editor's draft

-> http://www.w3.org/XML/XProc/docs/langspec.html

Vojtech: The label-elements step has a default value for the label which uses a hardcoded p: prefix.

Norm: Uh. Yeah.
... Maybe we should not give label a default value but instead express the semantics that are the default if it isn't given.

-> http://www.w3.org/XML/XProc/docs/langspec.html#c.label-elements

Norm: The penultimate paragraph needs to be fudged a bit too.

Vojtech: I expect that the parameter port on the XQuery step is for setting XQuery variables, but that isn't mentioned in the text.

Norm: Indeed, we should probably say something about that.

Henry: "p:" is used an awful lot and the namespace is used before 3.1. Maybe move up?

Norm: I will take px out where it isn't needed.

Vojtech: Use href instead of path for directory-list?

Norm: No, I think we did that on purpose to discourage people from believing that http: will work.

Vojtech: There are other cases where relative URIs are resolved.

Norm: I'll add a global note about relative URIs being made absolute wrt the nearest element.

Henry: The short-form case should also be called out.

Norm: Definitely.
... The editor will figure something out.
... Any other questions about 14 Apr draft?

Mohamed: For the definition of iteration-position, etc. we use 'integer'. For XPath 1.0 that doesn't exist, we should say that it's mapped to number.

Norm: No, we probably should say that.
... I'll see about making some global statement about XPath 1.0 vs. XPath 2.0

Proposed: The editor will make the corrections outlined above as well as editorial corrections suggested in email and we will publish this as an ordinary public working draft.

General agreement

Norm: I'll work with Henry to figure out when the publishing moratorium ends and we'll publish asap.

Paul: The moratorium ends on 28 Apr.

Norm: Let's publish on 1 May.

Any open issues we want to try to close before 1 May publication?

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

Norm: Henry, you wanted to think about value=, did you?

Henry: The fact that we can't be parallel to XSLT is what really bothers me. (Because we can't have content.)

Norm: I think it's more likely they'll be confused by using value when they meant select and vice versa.

Some discussion of what errors users might think are confusing.

Henry: select='div' is the problem case, right? Consider using that in rename.
... Given that the majority of our users have not yet seen this language, let's go for it.
... But make sure that we use the short form wherever possible in the document.

Alessandro: Another concern is that in many languages value holds an XPath expression, which could be confusing.

Henry: So that's also in favor of getting rid of value?

Alessandro: Yes, I think so.

Norm: Is there anyone who has reservations about losing value?

Vojtech: If we get rid of value, then we would need to fix a lot of strings in the standard library.

Mohamed: I think the main problem was that if we use select, then we'll get non-string results from some expressions.

Norm: I'm still on the fence, but I see that there are more issues.

Henry: And you don't get the short-form workaround for p:variable, which is the first example of value= in the spec.

Norm: Maybe we should ask.

Henry: I think we should *do it* and then ask. So that users can see the consequences.

Mohamed: I think we're opening a door we tried to close, about leaving all the type of value and option as string. Now we'll have the type from XPath 1.0 or 2.0 and we'll have to deal with that.

Norm: I think that's true even if we leave value= in.

Henry: It's slightly odd that for boolean valued options you can either write select="'true'" or select="true()"
... What you can't write is select="'true()'" or select="true".

Norm: Right. But that's the same in XSLT.

Proposal: Ditch value= and make it clear in SoTD that we're open to reintroducing it if there's pressure.

(And subject to the editor's ability to do this before 1 May)


Parameter input ports

Norm attempts to describe the status quo.

Norm: Should we treat this like our value= decision and remove it now, asking the users if they have problems with that.

Proposed: Pull out the magic, note it in the SoTD.


Add @fail-on-error to p:for-each/p:viewport

Norm attempts to describe the situation raised by James Fuller.

Mohamed: I asked for something like this for rename a few months ago. So you can tell if it did some renaming.
... I think if we do it for for-each, we should do it for other steps as well.

Alessandro: Another way to look at is to use an XPath 2.0 treat as expression.
... match="chapter treat as element()+"

Norm: Interesting.
... I think on balance, I'd rather not given the analsys that would be required to find other steps where it made sense.

Henry: I'm in favor of the status quo.

Proposed: Not for V1.


Empty document node vs. undefined context.

Norm: More consistent with XPath 2.0.

Mohamed: What's the consequence for someone converting from XPath 1.0 to XPath 2.0?

Norm: That expressions that relied on the empty context node will now be errors: fix your expressions.

Mohamed: I'm ok with it.

Alessandro: I agree too.

Proposed: In XPath 2.0 implementations, make the default context node undefined in those places where it's currently an empty document node.


Any other business?

Some discussion of future meetings; Norm will have to give regrets for 15 May and 22 May, Henry will chair.


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/24 19:58:33 $