See also: IRC log
-> http://www.w3.org/XML/XProc/2011/06/09-agenda
Accepted
-> http://www.w3.org/XML/XProc/2011/05/05-minutes
Accepted.
No regrets heard.
Vojtech: It's like current in for-each and viewport. It's the same type of thing.
Norm: I think you're right.
... I think for p:catch, we should just remove the word
"output" which I think was Mohamed's suggestion.
Vojtech: It occurs in two places.
Proposal: Remove "output" from the discussion of the error port where it's an input not an output
Accepted.
<scribe> ACTION: Norm to write an erratum for the incorrect description of "error" as an output port in p:catch [recorded in http://www.w3.org/2011/06/09-xproc-minutes.html#action01]
Henry: I've made no progress yet, hope to have something ready for next week.
Norm: Alex looked at xml:id and XInclude
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Jun/0007.html
Alex; Yes. I was able to get xml:id working quite well. It relies on DOM mutation events which work successfully in browsers where its supported.
scribe: Unfortunately, webkit
browsers don't support the mutation events API.
... That's related to XInclude because it talks about
maintaining references.
... XInclude itself also works quite well, with the exception
that the base URI property isn't used properly in some
browsers. But that's just a bug.
... If you programmatically change the base URI by
adding/changing the xml:base attribute, that has no effect in
some browsers. But it does work in Firefox.
... Long story short: you can implement it in JavaScript. But
if you have an implementation of this, then how does it get
invoked?
... In some browsers, if you put XHTML script tags in, those
scripts run. But in other browsers, e.g. IE9, then they don't.
So there's no universal way to start the process.
... It might be possible to do this with extensions, but that's
not standard browser behavior.
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Jun/0009.html
Alex: Is there anything to note about this in the spec? It should be said that xml:base is supposed to change the base URI.
Norm: Is it worth adding to the spec?
<alexmilowski> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12924
Alex: The browsers do support
xml:base, and HTML5 describes the right behavior, but it's not
clear what happens when you programmatically change the base
URI.
... You actually have to find and re-resolve the URIs on the
elements.
Murray: Are you suggesting that if you didn't rely on base URIs, that is if you provide the fully qualified URIs, that generally the browsers do what they need to do except for recursive XIncludes?
Alex: No. I'm saying that Firefox
does the right thing. The other browsers I tested don't do the
right thing. But that's a bug and I've filed them.
... And the HTML5 spec says that what Firefox is doing is the
right thing.
... What's not supported is programmatically changing the base
URI to effect descendent attributes. For example, after an img
src has been resolved, changing the base URI on an ancestor
won't cause the img src to be recomputed.
Murray: Are there utilities for doing base URI resolution? Like a unix filter that will expand URIs and give you back the fully qualified URIs?
Alex: You could *write* one. There isn't a standard API in the browser to do this.
Norm: XProc has a step to do this.
Alex: Because we have the base
URI property, we can control it. What the host language does is
up to them and should be made clear.
... We should make it clear that the right semantic is that you
resolve the URI against the base URI of the element and
xml:base controls that.
... There's no magic.
... That's pretty much what the HTML5 spec says.
Further discussion of the behavior of the base URI
Some discussion of what it means, or should mean, to change the xml:base value after a document is ... yeah, is what? parsed? rendered?
<scribe> ACTION: Paul to put the discussion of dynamic changes to xml:base on the XML Core agenda [recorded in http://www.w3.org/2011/06/09-xproc-minutes.html#action02]
Henry: This was background to
Alex's concern in this area. Coming from a completely different
perspective, the members of the team were saying that they need
XInclude functionality without knowing it.
... It was really just as background.
... We'd had this discussion of whether XInclude should be int
he profile we're hoping to sell to the browsers.
Murray: Years ago, I imagined a
world where you could use entities to pass along secret
messages. No one would rely in them so they wouldn't show up in
most tools.
... But every now and then someone would read a document that
used an entity to include a secret message.
... That's why I'd like to say something about these things in
XProc.
... We need transclusion, we've always needed it. That's why we
had entities in SGML. That's why Ted Nelson coined the
term.
Some discussion of the future of entities.
Murray: The case that I care about from GRDDL wasn't handled because we didnt have XInclude in our profile.
Alex: That's true, that's part of the reason we got here.
Norm: I think we're trying to get
there. Can we get the browsers to support XInclude, can we do
it in JavaScript if it's not part of what the browse does by
default?
... These are the sorts of questions we're trying to
resolve.
Alex: It's clear that entities are dead in the browser.
More discussion about profiles in general and support for GRDDL
<scribe> ACTION: Norm to include an explicit mention of satisfying the GRDDL faithful rendition property in the appropriate profile [recorded in http://www.w3.org/2011/06/09-xproc-minutes.html#action03]
<Vojtech> Implementing GRDDL in XProc: https://community.emc.com/docs/DOC-10276
None heard.
Some discussion of f2f meetings: TPAC is it for this year
Adjourned.