See also: IRC log
-> http://www.w3.org/XML/XProc/2010/06/10-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2010/05/27-minutes
Accepted.
No regrets heard.
-> http://www.w3.org/XML/XProc/2010/05/wd-comments/
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
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.
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.
None heard.
Adjourned.