XML Processing Model WG

Meeting 175, 24 Jun 2010


See also: IRC log


Norm, Henry, Alex, Vojtech
Paul, Mohamed, Murray


Accept this agenda?

-> http://www.w3.org/XML/XProc/2010/06/24-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2010/06/17-minutes


Next meeting: telcon, 1 July 2010?

No regrets heard.

Proposed errata

-> http://www.w3.org/XML/XProc/docs/xproc-proposed-errata

E01, update a non-normative note

Norm: I propose we adopt the XML Core model and put it in countdown for a week. If no one objects next week, we'll accepted it.

E02, clarify "decoded if necessary" in

Norm: I propose we put it in countdown for a week. If no one objects next week, we'll accepted it.

E01 and E02 are in countdown for a week.

Comments on XML processor profiles

-> http://www.w3.org/TR/xml-proc-profiles/

Norm: Issue 7, minimum processor profiles and XML Media Type

Alex: There's a lot of variation in what browsers do. Some of the browsers are currently buggy.
... One way to think about what we're doing here is to say what browsers SHOULD do.
... There's no better place to put this. It's not related to HTML5, 3023bis is being updated, it seems like there's an opportunity to reference this model from 3023.
... Browsers have a couple of ways of getting XML. One way is through the address bar. Another is via XMLHttpRequest.
... there are different expectations in the two cases; in the XMLHttpRequest case, scripts don't run and stylesheets aren't applied.
... There's very little out there that says what should happen, though the HTML5 folks think that XMLHttpRequest is relevant.
... If this was in the media type registration then that would be pretty definitive.

Norm: Yes. So isn't what the browsers do basically the minimum profile plus applying stylesheets?

Alex: No, because only IE reads the external subset.

Norm: But we could say that that's what they should do.
... though I guess we could have a profile that doesn't read the external subset.

Alex: The question is, should we have a profile that lines up with what web browsers do.
... in both cases.

Norm: So we could have two profiles for browsers, one for rendering and another for XMLHttpRequest.

Alex: We'd have to decide what happens in both cases and whether or not we'd want to say anything about stylesheets.
... How much of what happens when you put an XML URI in the address bar should be default processing and how much should be application processing.

Norm: Doesn't Associating Stylesheets say what to do?

Alex: No.

Henry: It's clear that we can't say what to do without a new version.

Alex: There are questions about how far we can go in our current charter
... From the W3C perspective, I think there should be a set of nicely orthogonal specifications that say what happens when you type a URI for an XML document in the address bar.
... The same should be true of the XMLHttpRequest object.

Norm: I think the HTML5 effort is derailing all interest in XML from the browser vendors.

Alex: But some of this is open source. I chased down xml:id in webkit for example, and found a bug that just says these three people decided not to do it.

Norm: So a minimal-minimal profile that doesn't read the external subset would be one possibility. I'd be inclined to leave stylesheet processing as application behavior.

Alex: Or we could have two profiles, one that builds on the other to do stylesheet processing.
... I think if we wrote this down carefully, it would get implemented.

Norm: So what would you change in our current document?

Alex: Right now, if you dropped XInclude from the basic profile, that would be what I'd like to see.

Norm: Right, we could spread things out a little more so that we had more choices.

Henry: The question is, where do we do that?
... There's no place in our profile spec to say what browsers should do. The question then is, where do we lobby to have browser behavior changed to reflect one of those names.
... For example, in the current working draft of XMLHttpRequest there's a section that says "parse the XML per the XML Specification"...
... We could lobby the editor to change that to say that it SHOULD do whatever level of processing we think is appropriate.
... The problem I have for the browser case is that I don't know what spec ougth to change.


Henry: There was going to be a "user agent something or other" good practices for browsers document, but I've never found it.

Alex: There are two things here: the sequence of processing to produce an infoset, and secondarily the question of rendering.
... wouldn't it be nice to specify the order of transformations and an interpretation for them.
... including things like the application of fragment identifiers in the transformed HTML
... we could go that far.

Norm: I'm not sure that's in scope and I'm not sure it would be greeted as a friendly ammendment to current processing.

Norm feels deeply pessimistic about the future in this regard

Norm: I'm not sure where this is going.

Henry: I think in the short term we should focus on getting a WD of this document out.

Alex: There is one thing we could do, we could factor out XInclude from the basic profile.

Norm: Perhaps I'll try to add two more profiles so that we have a different place to start.

Henry: I'd like to keep Basic as it is and add names below it. Or call the four step one "Standard" or something aggressively positive.

Any other business?

None heard.


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/06/24 16:02:48 $