See also: IRC log
-> http://www.w3.org/XML/XProc/2008/01/31-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2008/01/24-minutes
Accepted.
No regrets given
-> 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
Accepted.
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.
Accepted.
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
Accepted.
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> 5.7.1.3 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> 5.7.1.3 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 5.7.1.3 about the value case and point to 2.8.2 from there.
None.
Adjourned.