See also: IRC log
Date: 7 February 2008
<scribe> Meeting: 101
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<richard> hmm, i suppose that's me, but it's not the right number
-> http://www.w3.org/XML/XProc/2008/02/07-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2008/01/31-minutes
Accepted.
No regrets given
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
Norm attempts to summarize.
Norm: Do we want to make it possible to exclude prefixes?
Henry: What's wrong with telling
processors they should construct documents as if serializing
the document, removing all inherited namespace bindings from
the root, and reparsing?
... That is, remove everything that's inherited.
... In the 0.1 percent case, you'd have to bind a namespace
several times because you were using it in several inlines.
Norm: That seems way more confusing than just adding the attribute.
Alex: Considering we have to produce a document from p:inline, you have to do a little bit of work. So having to do a little more work doesn't seem that bad.
Henry: If you've got an infoset, you're going to have to walk through and fix all the nodes.
Alex: I don't think so.
Henry: In order to prevent serialization from doing the wrong thing further down the line, you're going to have to look at all the namespace information bindings.
Some discussion of how complicated this really is.
<ht> http://www.w3.org/TR/xslt20/#lre-namespaces
Henry: What that says is you've got to walk the tree and prune the namespace nodes.
Richard: XSLT's mechanism is slightly more complicated than the excluded prefixes; the xsl: prefix is excluded and then there's an alias that lets you put it back in.
Norm: Bah.
Alex: I wonder if there's a simple thing that we have a problem with: the document element is going to inherit all the in-scope namespaces. The simple question is, do we break that relationship?
Henry: The argument that says inline is very-very parallel to literal result elements in XSLT suggests we should make it very parallel.
<alexmilowski> +1 to that.
Henry: We exclude the pipeline
namespace, we provide exclude-result-prefixes, and we add the
aliasing.
... If we think it's parallel to XSLT LREs, we should change
things to make it parallel.
<ht> HST didn't say 'add the aliasing', but might be persuaded. . .
Henry: Because we can stand in a
better place, I'm going to try to do it the following
way:
... what the ... nevermind
... what I was going to say was that we exclude them from this
element where they're inherited. But that's too hard and
complicated.
<scribe> ACTION: Henry to draft a spec change for providing exclude-result-prefixes on p:inline. [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action01]
Richard: We don't need a dual to the xsl:exclude-result-prefixes attribute, and you only put them on a p:inline element, not on some higher element.
Henry: I guess you should be able to put it on the p:pipeline or p:declare-step?
Richard: No. Remember that the 90% case is you don't do this at all.
Henry: Proposition #1, there's a dont-exclude-pipeline-namespaces attribute which is false by default. Or there's an exclude-pipeline-namespaces attribute which is true by default.
Richard: Is it used for anything else in XSLT?
Henry asserts its not
Richard reads something from the XSLT spec about security and namespace aliasing.
Scribe distracted for a moment
Richard proposes using another step if you really need to have the pipeline namespace.
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Feb/0017.html
Alex summarizes the proposal, including an addition to control replacement
Henry: Remind me, did we reach closure on a variable versus a function?
Alex: I think those of us who
wanted this change wanted the variable.
... My rationale is that some APIs make it easier to set a
variable than a function.
Henry: As we've repeatedly
commented, implementations don't have to use XPath at all in
the defaulted case.
... It's easy to optimize this if you want to.
Alex: One tweak is to say that the label attribute is optional
Some discussion of function vs. variable.
Alex: Inside a step, it seems
like you need an API that you might not otherwise need inside
the step. Things like viewport can be very different. The API
for steps might be simpler, cleaner.
... Writing things in steps seems different than writing things
in the core language.
Shall we adopt Alex's proposal?
Accepted.
Alex: With a replace option?
Norm: I think so, any objections?
None heard.
Norm: I think this is a desire to compute serializatin parameters and pass them in dynamically. Maybe useful, but not a V1 feature in my mind.
Henry: Besides, there's a
workaround.
... You can write the document and the compute the options from
that document.
Proposal: No change to support this use case in V1.
Accepted.
<scribe> ACTION: Alex to reply to the submitter. [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action02]
Norm: I don't know why I put this on the agenda, it's editorial. Let's just do it.
Accepted.
Alex: I think we should drop the
ommission of content-* headers.
... I don't think I want to go into parsing the headers because
the header parsing is dependent on the header, they don't all
take parameters.
... I think its overkill even if it is generally true. And I
don't think you'd gain anything.
... in the case of charset, the parameter has already been used
to decode the content.
<scribe> ACTION: Alex to consider any clarifications that might need to be made to p:http-request. [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action03]
At the very least, go ahead and remove the restriction on content-* headers.
Topic #111. Additions to implementation defined section
Norm: I suggest that we whatever XPath 2.0 does wrt Unicode versions.
<scribe> ACTION: Norm to add the Unicode version text to the spec [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action04]
Norm: I don't think we need to say anything about warnings, but I'm prepared to be persuaded.
Alex: Programs can generate warnings if they want.
Proposed: We'll say nothing in the spec about this.
Accepted.
Norm is inclined to agree with the commenter
Richard: What does add-attribute do if the attribute is already present
Norm: We don't say. That we need
to fix.
... Let's take these one at a time.
... Are we going to rename add-attribute to
insert-attribute?
Alex: I'm not sure insert is the right word
Norm: I don't hear any
support.
... So I'm inclined to leave insert the way it is; we might
relax the restrictions in the future.
Richard: And if the document has a PI, then that gets inserted, so we can't rename it insert-element.
Alex: And we can have before and after, so it isn't a child.
Proposal: do nothing.
<scribe> ACTION: Alex to fix add-attribute wrt existing attributes [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action05]
<scribe> ACTION: Alex to fix insert so that it doesn't always imply child. [recorded in http://www.w3.org/2008/02/07-xproc-minutes.html#action06]
Accepted.
None.
Adjourned.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/nodes/namespace nodes/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: PGrosso, Norm, Ht, ruilopes, +44.131.467.aaaa, richard, alexmilowski, Andrew, Murray_Maloney Present: Paul Norm Henry Rui Richard Alex Andrew Regrets: Alessandro Mohamed Agenda: http://www.w3.org/XML/XProc/2008/07/07-agenda Found Date: 07 Feb 2008 Guessing minutes URL: http://www.w3.org/2008/02/07-xproc-minutes.html People with action items: alex henry norm[End of scribe.perl diagnostic output]