Meeting minutes
Review of action items
Revert wording to attributes: completed
Add wording to forbid xmlns attributes: completed.
Steven: I note that this means we need new errors.
Norm: I'll do that.
Insert Michael's ambiguity text: completed.
Steven: I removed the remark about "sentences" and just talk about parses.
Contact Prague: completed, but have not heard anything.
Version declaration: completed, but we still need to discuss how exactly we want to do it.
Version declaration discussion
Steven: A grammar must conform to the syntax of the version declared or implied.
… That's a new conformance requirement.
Some discussion of "must" with respect to producing a warning if the version declaration is not recognized.
Michael: In other cases, what we do for warnings is put attributes in the ixml namespace in the output.
… Maybe add unrecognized version should be a value of state?
John: I think this depends on what the APIs of the processor are.
… I'm not terribly happy that failure gets indicated in the output, but that's not really an issue.
… There are potentially different channels. And we should require everything to go down that channel.
Bethan: The only thing that we can be certain of is that the spec specifies that you have to serialized as XML.
Some discussion of the ixml:state="fail" case for failed parses.
Michael: If you have other channels and want to produce output on them, that's okay.
… We have a "single channel" model of the processor. By analogy with ambiguity and failure to parse, I think possibly a signal on the root element of the output may be a good thing to do here.
Steven: Instead of saying you must issue a warning, the fact that the version didn't match goes on the root element if it found a valid interpretation. (Otherwise, it'll reject the grammar anyay.)
Michael: I would want the information that the parser didn't recognize the version in any case.
Norm: I'm okay with that.
Some discussion of the case in the failure state.
Tom: Can I suggest that rather than reusing ixml:state, we have a second attribute?
… That is only required when we don't recognize the version being used.
John: I like that.
Michael: Exploring Tom's suggestion of a separate attribute, I wonder what goes in it
Tom: I think that's an open question, but one thing I'd like is the version as declared and I think there's an argument for saying unrecognized. Or perhaps that it's there is enough to say that it's unrecognized.
Bethan: If we just did ixml:version= and the version used, would that be enough? Given that'll match the version requested or not.
Steven: The problem is that you're not always going to be looking at the output.
Michael: As a user who has spent a lot of time puzzling over why things haven't worked, I'd like to know what version you thought I requested.
… I thought I was asking for 23, why did you think you couldn't parse 2.3?
Norm: All we say is that you should put useful information the error document.
Bethan: I think you've missed the point. I think what Michael is saying is that the version information is not necessarily relevant to the failure.
John: If you've got a failure document, you can put all sorts of stuff in there. I'd like to have something when you succeded.
… The downstream processor has to look at a bit of XML to tell if it's an error report. The model we've got requires pipelines to do that at the beginning.
Tom: I just wanted to repeat that I think it's important in an apparent success. Maybe even more important. Two attributes: one that said what was expected and one that said what was used.
… If there's no problem there should be no version attribute at all. If the processor thinks it's recogized the version, it should leave them both out.
Michael: I agree with everyone that says it may be more important in the case of success than in failure.
… But in general, if a precondition wasn't satisfied, it's relevant no matter what.
… If the processor doesn't recognize it, I'd like a signal. I've come to believe that simpler is probably better. A token meaning "I didn't recognize this version" for ixml:state is the easiest thing.
… I think everything else is useful and good processors will provide it.
Bethan: I see the point about using it in state, but what about ixml:version-missmatch="requested used" ?
… That would mean an extra attribute, but it would be more informative than just a single token.
Norm: I support simpler. Just a single token.
Tom: Maybe in v.Next we can do more.
Proposal: Add a new token to the ixml:state attribute, "version-mismatch".
Accepted.
Discussion of <prolog version="x.y"> or <prolog><version string="x.y"/></prolog>
Some discussion of why all the values are in attributes.
ACTION: Steven to rewrite the prolog syntax to support <prolog> containing <version>
ACTION: Steven to rewrite prolog to deal with the warning
Issue 83, tmark on charsets
Some discussion of the typo.
John: Does it make sense to have another mark for charset so that "+" can't appear?
Norm attempts to clarify that (he thought) John was referring to adding a cmark that didn't include "+"
Michael: I think I'd prefer that.
Steven: I pointed out recently that actually an insertion is a completely different beast.
An insertion should be a new kind of terminal.
Michael: I think that makes sense.
ACTION: Steven to change insertions into a new kind of literal instead of a mark
Release planning
Norm: If you get us a draft, we'll review it for editorial changes for next week.
… We should agree that the draft next week is the 1.0 draft.
… Everyone should raise issues for anything they'd like changed on the home page for the release announcements
ACTION: Steven to try to reach Jirka directly re: Prague
Adjourned.
ACTION: Norm add new conformance errors for well-fomed text