Accept this agenda?

-> http://www.w3.org/XML/XProc/2011/10/13-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2011/10/06-minutes

Accepted.

Next meeting: telcon, 20 October 2011?

No regrets heard.

XML processor profiles issues

-> http://www.w3.org/XML/XProc/2010/11/lc-comments/

-> http://www.w3.org/XML/XProc/docs/xml-proc-profiles.html

Norm: We've got a bunch of open issues. Henry, want to give us an update?

Henry: The only changes I've got planned are the one's minuted last week. Renaming of the profiles, renaming B' to S, and changing of a bit of wording in 4.2.3.

Norm: Thank you, Henry.
... Let's skim over the open issues and see how many we feel comfortable marking as closed.
... I think issue 1 is resolved.

Vojtech: I think so.

<scribe> ACTION: Henry to review isssue 3 (2) and 3 (3) as editorial making changes as the editor sees fit [recorded in http://www.w3.org/2011/10/13-xproc-minutes.html#action01]

Henry: WRT comment 4, add a sentence to the beginning of section 3 clarifying how the classes are derived from the table below.
... Comment (5) is resolved by section 7 in the latest draft.

Norm: That leaves (1); Liam objects to calling the Infoset a data model.

Henry: If I changed it to "the infoset or data models that capture similar information"...is that OK?

Paul: Sure.

Norm: Issue 4 was a thread we did about browsers. I think we can close that.

Alex: It's possible the browser could do more, but I don't think we're going get a better story.
... I'd like XInclude, but we don't have a profile for that the browsers could do.

Henry: I think it's fine; in so far as the point of the full profile is that you basically have the document that the author committed to, I think having XInclude but not external entities is odd in that respect.

Alex: Unless you're in a DTD-less world, then it's not odd.

Norm: Issue 5 is about test cases, but we're going to try not to do CR, so we can close it, yes?

No objections

Norm: Issue 6 from the Core WG.
... I think we've removed "recommended" which helps, and I think we'll need something in the introduction to spell out why we chose the profiles we did.

<scribe> ACTION: Norm to attempt to draft that prose, cf. cmsmcq's comment 1 [recorded in http://www.w3.org/2011/10/13-xproc-minutes.html#action02]

Norm: Issue 7; I don't think we're going to get the browsers to move on that.

Alex: The point there was the second bit, having standalone have an interpretation.

Henry: The browsers aren't going to pay attention to the standalone declaration.
... Unless we change the XML spec to change the default. The problem is that the default is standalone=no. So if we ask the browsers to change to make standalone=no an error, we'll break all XHTML. It's a lose-lose situation.
... The one thing we could imagine doing is to say that there's a media-type dependent default which is standalone=yes. What we'd be asking the browsers to do is two things: (1) give an error in the presence of an explicit standalone=no, and (2) give an error for non-HTML XML unless there's an explicit standalone=yes

Norm: In 1997, maybe. But today it's just not worth it. We'd be asking every user serving non-XHTML XML to change.

Henry: So how would Core feel about saying that the XML XHTML5 spec can default standalone=no
... If we don't do this, then we should have raised an issue on XHTML5 saying that they're not raising an error when XML says they should.

Further discussion, leading to the observation that standalone is a validity constraint

Paul: I'm happy to have the Core WG say something if it helps make things work better.
... as long as it doesn't rewrite the XML spec.

Alex: I think the question is, if you look at the combination of our new document with the smallest profile and the XHTML5 spec, what's the interpretation of the standalone attribute.

<scribe> ACTION: Paul to put standalone on the Core agenda. [recorded in http://www.w3.org/2011/10/13-xproc-minutes.html#action03]

Norm: Let's skip 8 for the moment, I think we've resolved 9 by removing the word "recommended"
... I think 10 is resolved.
... I think 11 and 12 are just observations, not comments on the spec
... I think 13 is resolved by adding section 7

<scribe> ACTION: Henry to add a note to the effect that we are talking about static parsing, not dynamic environments [recorded in http://www.w3.org/2011/10/13-xproc-minutes.html#action04]

Henry: issues 14 and 15 are informational, not comments on the spec

Norm: Issue 16 is clearly a bug.

Any other business?

Norm encourages everyone to read xproc-dev

Adjourned