W3C

- DRAFT -

XML Processing Model WG

Meeting 173, 10 Jun 2010

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Henry, Murray, Vojtech, Alex
Regrets
Mohamed
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

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

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2010/05/27-minutes

Accepted.

Next meeting: telcon, 17 June 2010?

No regrets heard.

Comments on XML processor profiles

-> http://www.w3.org/XML/XProc/2010/05/wd-comments/

Comment 1, whitespace

Alex reports on his action to investigate Webkit

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2010Jun/0003.html

Norm: So webkit ignores "element content whitespace", that is, reports all whitespace.

<ht> http://lists.w3.org/Archives/Public/public-xml-core-wg/2010Jun/0003.html

Henry: I sent email to Richard and DV, asking what their parsers did and what they thought of the issue.
... Richard's reply was consistent with what we said: there's nothing to stop a non-validating parser reporting correct values for "element content whitespace".
... but RXP does not do so.

Norm: So the evidence we have gathered so far suggests that in practice if you aren't validating you don't get information about "element content whitespace"

Alex: If this is the basic profile, why would it hurt to say that all whitespace is preserved?

Murray: Let's assume that there was a profile that included validation. Couldn't we then say for each profile, these are the infoset items we expect to be reported by running this process.
... And make a note that distinguishes which ones are different.

Henry: I think what we want to say is, for each profile that we define, you can count on the presence and values of all of the following infoset properties.
... And that it must be the case that the presence and values will be identical across any processor that supports this profile.
... but you can't depend on anything about properties that aren't in this list.

Murray: I don't think we'd want to allow the "A" profile to add stuff that's in the "B" profile. You can't mix and match.

Henry: Validation is special, but I think we can fix that.

Norm: But the properties are not all independent. Validation requires element content whitespace for example.

Alex: Can't we have two "bases" to our layer cake, so it's really a kind of matrix?
... in one case the validation was performed before hand, by some magic, and in another case perhaps we require the validation to be done.

Murray: My feeling is that we should be starting with full validation, then lowering the bar.

Norm: In 2010, I don't want to encourage validation with DTDs and nothing we're saying has anything to do with schema validation.

Alex: Our minimum profile is matching pretty nicely with what browsers do.

Norm: But we require the processor to read external markup declarations.

Alex: I didn't say it was perfect, but we could fix that.

Henry: I was resistant. There's no reason to set a non-bar.

Murray: I don't know what that means.

Henry: I don't think we need a profile that doesn't set the bar higher than "do what the XML rec says".
... Until and unless we settle the question about whether we're setting lower bounds or stronger invariants, I don't think that argument goes through.

Some discussion of external subsets and browser parsers.

Murray: I thought we were going to try to address reality by naming the processes.

Henry: Overal, this spec is like the infoset spec, it defines choices with names which allow other specs to make determinate choices and save themselves settling all these issues over and over again.
... And as such we thought the inventory of profiles we'd define are the ones we thought other W3C specs would want to use.
... So there's a little bit of circularity there, by calling the minimum profile what we have, we're saying this is what the minimum should be.
... Maybe that's not an appropriate goal for this exercise.

Alex: I think we should try to align with current/future expectations of what the browsers are going to do with XML.

Murray: I think we might want to deprecate the profile we think is too small

Henry: Or at least a health warning.
... I suggest we add a profile that only requires XML base and to also see if we can find a form of words along the lines that Murray suggested that talks about infoset properties and describes what's gauranteed for each profile.
... I'm less clear of what to say about validation, but I think it might just fall out of the exercise.

Murray: It's not the validation part that's problematic for me, it's the changes to the infoset.

Henry: So consider two different ways of stating the invariant wrt white space:
... 1. two processors which implement these profiles cannot be counted on to provide the same values in all circumstances for the element content whitespace property for characters
... 2 and only in a putative fourth profile will the results be the same

Murray: Can we create a "hello world" document that demonstrates the differences between these profiles?

Henry: If we go in the direction I suggested, then we'd only show the properties that you can be sure will be the same.

Murray: If we expressed these differences in RDF, that would capture the attention of some more people.

3 XML Base

Murray: I think he's saying XInclude covers it

Henry: But it doesn't! If there are no XInclude elements in the document then XInclude doesn't tell you anything.

Murray: I thought that one was really simple

Norm: Can you try to follow-up, Murray?

Murray: Sure.

Any other business?

None heard.

Adjourned.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/06/11 19:18:11 $