XML Processing Model WG -- 19 Mar 2014

Date: 19 Mar 2014

<scribe> Meeting: 245

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

ok, ht, but if you need to say something you may have to type it :-)

(did you hear what I said to you?)

zakim EMC is Vojtech

<jfuller> coming

<jfuller> 2 more mins

<alexmilowski> lol

Accept this agenda?

-> http://www.w3.org/XML/XProc/2014/03/19-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2014/03/05-minutes

Accepted.

Next meeting: 26 Mar 2014

No regrets heard.

Vojtech gives regrets for 26 Mar

Review of open action items

<jfuller> I am here

Norm has done some of his, see the errata document

Review response to bug 21005

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21005

Jim proposes adding a may requirement to make static compilation possible.

Norm proposes that it should be a should at least.

Norm muses about why we have "optional options". In XPath 2.0 I think we have more leeway because we can say that the default value is the empty sequence.

The fact that XProc 1.0 conflates the notion of variable binding

across the static and dynamic contexts means that attempting

to compile XPath expressions in a purely static way will still

require determining whether or not there are bindings for all

the XPath variables at runtime.

<jfuller> +1

<ht> +1

<alexmilowski> +1

<ht> or /variables in the expression/

Norm: I added that to the bug. We'll see what the commenter says and get back to adding errata shortly.

Review proposed errata

-> http://htmlpreview.github.io/?https://github.com/xproc/specification/blob/xproc10/10errata/proposed.html

Vojtech: The first comment I had was about p:choose;

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Mar/0016.html

Vojtech explains.

Norm: I think you're correct.

<jfuller> 'to invoke'

<jfuller> ?

Vojtech: Sometimes we say 'connected' and sometimes we say 'bound' and we don't clearly define those terms.

Henry: I agree absolutely.

Vojtech: Does connected meaning consumed or consuming?

<ht> "If a (non-primary) output port of a compound step is left unconnected"

Norm: I have an action to fix that.

<ht> "An output port may have more than one connection: it may be connected to more than one input port,"

Norm: But I hadn't seen the connection to bound.

Vojtech: In 2.2 you end up with a different picture depending on which side you look at.

Henry: In 2.2, three paragraphs apart, one use of connection is pull and one is push.

<ht> So I'm glad to hear that Norm has an action to fix this

Vojtech: Another distinction between connected and bound: for output ports it is an error if they remain unconnected. That made me realize that connected means being consumed.

Norm: It just means ... connected

Vojtech: If you look at it from an implementation standpoint, pull or push, it can be different.

<ht> Not just connected -- for _compound_ steps, the output port can be connected twice

<ht> ... Once to pull its value

<ht> ... The other to push its value

Norm: Thank you, I see the problem more clearly now.

<ht> Yes, yes we are

Bugs against 1.0

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21053

In the p:wrap case, unless you wrap "/", the base URI doesn't change. Right?

<jfuller> what does p:base-uri() return

<ht> Base URI changes all over a document

<ht> If you mean the base URI property in the infoset

In the p:wrap case, unless you wrap "/", the base URI property of the document in the infoset doesn't change.

Do we agree with that?

<ht> NOOOOIO

<ht> Because it's _elements_ that have base URIs!

Don't document infoset items have base URIs?

Vojtech: It feels to me that in p:wrap-sequence alone, if you wrap a single document or 10 the base URI of the result should be consistent.

Norm: in the wrap-sequence case where we're creating a whole new document with a new root element

Alex: I think it should be empty

<ht> NOTE: This is wrong, in the def'n of p:xinclude: "The included documents are located with the base URI of the input document and are not provided as input to the step."

<ht> We're not talking about document URI

<ht> +1

Norm: I think I heard "empty" as the proposed value for base-uri from p:wrap-sequence, does anyone disagree?

None heard.

Norm: I think a p:wrap that wraps "/" should behave exactly like p:wrap-sequence on that document, does anyone disagree?

None heard.

<ht> Note that that is _only_ on the document node and the document element node

Henry: We need to fix XInclude. We're being too glib in talking about base-URIs. All of the elements in the document potentially have base-uri properties.

We shouldn't think about fixing this without doing fixup.

Henry: the part about the base-uri property is that it provides the base for resolving URI references.
... It doesn't get copied but you have to look up the chain to your ancestors until you find a base URI

<jfuller> base uri fixup reference - http://www.w3.org/TR/2004/REC-xinclude-20041220/#base

Henry: What that makes me think is that the result should have a base URI on the document node and that's it.
... It follows that if you wrap it, in order to make the relative references work, you should copy the base URI onto the element that used to be the document element and is now submerged.

Alex: If you think of it conceptually, they're equivalent to "this XInclude" where this document has no URI/base-uri. Or it's embedded.
... I wonder if the outcome is similar.
... If you look at it from an XInclude perspective is it similar, is it the same.

<jfuller> the right base uri fixup reference - base uri fixup reference

<jfuller> http://www.w3.org/TR/xinclude/#base

Alex: It would be nice if these things could work in the same way. We need to think this through more carefully.

Norm: I'll make this base URI question an explicit agenda item for next week.

Any other business?

Adjourned.

- DRAFT -

XML Processing Model WG

19 Mar 2014

Attendees

Contents