See also: IRC log
No regrets heard.
Alex reports on his action to investigate Webkit
Norm: So webkit ignores "element content whitespace", that is, reports all whitespace.
Henry: I sent email to Richard
and DV, asking what their parsers did and what they thought of
... 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
... 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
... 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
... 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.
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?