See also: IRC log
Jim points out a missing action.
ACTION A-236-01: Alex to prepare a note with the table of use cases and solutions from V1.
Henry: On the question of
validation, I see three possibilities.
... 1, say validation is so last century it isn't worth addressing. No one cares anymore.
Henry: 2, oh, all right, DTDs were a key part of XML, some of us still like them, so we'll add a fifth profile, the same as three or four with validation
<jf_2013> XML Proc Profiles - http://www.w3.org/TR/xml-proc-profiles/
Henry: 3, give a normative
paragraph that describes how to construct names for the
... Not only will you say you could do it, we'll tell you how to do it.
... We could elaborate the last sentence of section 7 to say "we recommend the following language to be used..."
... I think I like 2 the least.
Norm: I agree, DTDs really are last century.
Jim: If there is validation, is the sequence implied?
Henry: The only case where there's any dependency is in profile 4.
Some discussion of the order in which validation can occur. In particular DTD validation during parsing and other kinds after construction of the initial infoset.
Alex: Michael makes this point, he says there are eight or more, and that's why we're not doing it.
Henry: On the other hand, this is a classic case of "if there's a complicated thing to define", leaving it to everyone else to do is less than helpful.
Alex: But these are the base specs.
Henry: But this conversation makes it clear that the implication of section 7 that you can say "I want the full profile with DTD validation" and be done and that's not remotely true.
Alex: I'm not even sure we have a consumer for this spec, do we really want to add more complexity?
Some discussion of whether or not anyone expects validation.
Alex: No other format talks about validation, it's one of the reasons it's bad.
Jim: Once you get to a significantly complex application, validation has to come into play.
Alex: I don't disagree, but when people think about the first thing you do when parsing a document they aren't thinking about validation.
Henry: I think we're all agreed it's going to be a layer, the question is are we going to give terminology and structure to that layer in this document.
Jim: Or we could add an optional step to each profile.
Henry: Edit 2.3 and 2.4 to put the hooks in for validation.
Norm: I'm tempted to try to do the elaboration Henry suggests in section 7. It would be an improvement to the specification irrespective of whether or not it satisfies Michael.
ACTION A-236-02 Henry to draft a revision to section 7 that provide instructions on how to specify what you want with respect to validation.
Discussion of the classification of facets
ACTION A-236-03 Henry to draft a revision of paragraph 3 in section 1.1 (or thereabouts) that makes explicit the fact that there are other facets (API, memory model, etc.) that are not relevant to this specification.
Norm: With respect to standalone, I propose a new paragraph that says effectively, "standalone was a mistake, it doesn't work, we explicitly ignore it."
ACTION A-236-04 Norm to draft a new paragraph for 1.1 that makes our decision to ignore standalone explicit and provides a rationale for it (wrong default, often incorreclty used, largely useless)
Some additional discussion in which Norm observes that the phrase only occurs five times.
Norm: So we could just reword those sentences in 2.x?
Henry: Yes, go ahead.
ACTION A-236-05 Norm to change the XPP spec to replace the phrase "corresponding to ..." with something more direct.
ACTION A-236-06 Henry to remove the seventeenth-century capitalization in the XPP spec.
ACTION A-236-07 Norm to provide a definition of the word "profile".
Henry: The XML spec makes the distinction between reading and processing, that's why we do.
ACTION A-236-08 Henry to respond to Michael about the distinction between reading and processing
Jim: Didn't we do what Michael requests in "relations to current practice?"
Henry: I thought so.
Jim: I think Alex took a wack at it.
Alex: I looked at what the webkit and firefox browsers do.
<jfuller_2013> BRowsers and profiles (Alex) - http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2011Apr/0014.html
Alex: Saying I have an XML parser and it doesn't do X isn't necessarily the right way to look at it, you can provide options, you can choose to get different profiles out of it.
Jim: I think we don't have a backstop profile, one that doesn't do XML base
Vojtech: I think we should have a reasonable intersection with reality, it may be fine if there are parsers that don't fall into any of our profiles, as long as there are enough that do.
Alex: What a parser does in the context of an application is just too broad to make this kind of analysis useful.
No more telcons until after the face-to-face.
See you all at the f2f.