XML Processing Model WG

Meeting 100, 31 Jan 2008


See also: IRC log


Alex, Paul, Rui, Alessandro, Norm, Henry, Richard, Mohamed, Andrew [x:22-]


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/01/31-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/01/24-minutes


Next meeting: telcon 7 February 2008?

No regrets given

Last Call Comments

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

Comment 100: cherry picked items

Should we add exclude-prefixes to serialization?

Alex: It'd be nice, but there's no standard serialization control for it

Henry: Why?

Alex: XQuery doesn't have it.

Norm: I don't have any recollection of a technical reason why it wasn't part of serialization.

Alex: I don't see anything in the serialization spec about excluding prefixes.

Norm: Clearly it can be done, do we want to do this in XProc 1.0?

Alex: It's critical if you want to send the output to IE.
... But implementors could do this outside of the spec.

Norm: We could let implementors do this as an extension.

Alex: It doesn't even have to be an extension in the pipeline; it could be in how you run the processor.

Henry: Gee, this is on the margins.
... Fussing with namespaces and serialization is something on which one can waste arbitrary amounts of time.

Alex: Implementors have lots of ways, it's a question of whether we make it a requirement.

Henry: With my implementors hat on, I'd sort of rather not...

Alex: Wouldn't an XSLT step at the end of the pipeline do it?

Norm: I'm not sure.

Richard: I'm not sure I understand the issue.
... In XSLT, exclude-result-prefixes is only about literal result elements in the stylesheet.

Norm: Ok, so is there anything comparable?

Ricahrd: If the pipeline itself binds some prefixes, then they're in scope for literal elements in it.

Henry: Like an inline document.

Some discussion of what the namespace bindings are for an inline document

Alex: You could do this with a new step.

Norm: I don't think we want to add this to serialization and I don't thnk we need to do it for any other reason.

Henry: Someone is free to create a simplify-namespace step and we can adopt it for V.next if it's widely supported.

Proposed: No, we aren't going to add anything for exclude-prefixes


Next up, should the 'path' attribute on p:directory-list be renamed?

Richard: If I were renaming this, I'd probably call it something like 'directory-name'

Norm: Nikolay followed-up proposing just "uri" on the basis that it might support ftp:, jar:, file:, etc.
... On that basis, I think I'd rather not change it.

<MoZ> what about location ?

Norm: Most implementations are only going to support file: URIs on the local host, so "path" makes some sense.

Alex: Location?

Richard: None of these is obviously better than "path".

Proposal: No change.


Adding a scheme to p:label-elements that generates an ID from an XPath

Alex: That would require another option

Some discussion

Richard: I've found that you often want to combine all sorts of possibilities.
... for example, an XPath that gives you the count. I did it with a C-like format-string. It gets passed the prefix, suffix, and label.

Some discussion of the possibilities

Richard: If prefix/suffix can be XPaths then in the XPath case you can just say that the label is '' so that you just get the concatenation of prefix and suffix.

Henry: We can always use an XPath and just require implementors to short-cut the simple case.

Alex: I think I'm with Henry, we take three options and we make them into one.

<ht> pp:count-elements()

<ht> It's nice that Alex likes my proposal, I like his

Norm boggles at a step-local function.

<ht> Use a variable

Richard: I think it's entirely reasonable for steps to have local functions.

Henry: I like adding a variable. I like saying impl's must bind $p:index to a value for the evaluation of this expression.

Norm boggles harder

Richard: To say this adds something is no more true than saying that XSLT adds a bunch of stuff.
... From the pipeline perspective, it's just a string. The label-elements step is the one doing the evaulation.

Norm: I think we've drifted far enough that we need a proposal.

<scribe> ACTION: Alex to draft a proposal for this change. [recorded in http://www.w3.org/2008/01/31-xproc-minutes.html#action01]

<ht> HST believes the proposal is to replace 'prefix', 'suffix' and 'scheme' with 'label', with default value concat('_',$p:index)

Comment 102: Default bindings for non-primary inputs

Norm tries to describe the proposal

Alex: That is weird. That's not what you want in most cases.

Proposal: Remove default bindings for non-primary inputs


Comments 107: Options in XSLT match patterns

Henry: If 2.8.1 doesn't apply, then don't we need to say something similar

The question of whether prefix is in-scope or not is open

Or maybe it isn't

Mohamed: Can we say that XSLT match pattern in XProc doesn't allow variable references, even if it's in XSLT2.
... We leave it for V.next to say how we do this.

Henry: Section 2.8.2 says explicitly that there aren't any variables in steps.
... We can close this issue by saying, 'use select'.

Richard: I'm now a bit confused by this description of the XPath context

<ht> introduces 'select' and 'value' and explains that in-scope options are available for access by variable references in 'select' expressions

Richard: What 2.8.2 should say is "except when otherwise specified by the step documentation"

<ht> should point out that per 2.8.2 if a option 'value' is used as an XPath, those bindings will _not_ be available

Richard: In fact, almost all these things do say "unless otherwise specified by the step"

Norm: Editorial carelessness

Richard: In fact, the XPath 2 case says that, we just need to fix the XPath 1 case.

Henry: We should be clear in about the value case and point to 2.8.2 from there.

Any other business



Summary of Action Items

[NEW] ACTION: Alex to draft a proposal for this change. [recorded in http://www.w3.org/2008/01/31-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/02/07 17:13:13 $