Meeting minutes
Norm attempts to scribe.
Review of action items:
Media type, action continues.
Status reports:
Steven has nothing to report.
Norm reports that his implemenation passes almost the whole test suite.
Michael reports that he's in the process of reconstructing his test harness after a disk failure.
… I've created a schema for test reports, if anyone is interested: consult the email and follow the links.
Norm reports that he has a test suite driver that runs Michael's test harness.
Michael: I think we should agree that Norm's PR for the test suite changes is good and someone should merge it.
ACTION: Tomos to make sure everyone has write access to the repo and accept PR #32
Review and resolution of bug reports and technical issues
Issue #24, does ixml have to match the whole input.
Steven: I'd like to add a new failure state that says the parse failed and the report that a prefix parse was possible.
Michael: Implementations are required to support or allowed to support?
Steven: For discussion.
John confirms that the intent is that you get the result.
Michael: I think there are some issues related to recognition of prefixes that I don't think we're in a position to answer well. For example, what if there's more than one?
Some discussion of whether or not multiple possible prefixes is ambiguous.
Michael: You can currently return a prefix, per the spec, except for the new defined value.
Steven: Do we agree then to close this issue? Does anyone know what Dave's position is?
Michael: I don't think he mentioned it.
Tom: That was the genesis of the error discussion, I think.
Some discussion of what Dave's position might be, but we don't know.
Norm asks what to do; Michael proposes a straw poll.
Tom: If the grammar doesn't recognize the whole input, that should be a failure. It should be dependent on the processor what they do with respect to the prefix.
Steven: Why?
Tom: I don't want to do it.
Some discussion of what implementations might or might not be able to do.
Tom thinks that if we do adopt the idea of a prefix, it should be optional for an implementation to do so.
John: It's not mandated that you can do prefix matching; it should also suggest that user-choosable whether or not the processor will do that. I might find myself in a place where I don't want to get a prefix match.
Bethan: Is a vxml document going to be returned that contains the prefix?
General agreement, yes.
Bethan: I think that sounds good. I might have a grammar that matches only a single sentence.
The scribe observes that we're arguing about the distinction <fail ixml:state="failed"/> or <sentence ixml:state="prefix">...</sentence>
<cmsmcq> [Bethan's example would make sense if her grammar accepted every prefix of the sentence "O Romeo, Romeo, wherefore art thou Romeo?"
John: I don't need the prefix in some contexts and I don't want it.
Steven: There's no extra work.
Michael: Not quite. If I know it went wrong at position 100, even if it matched the start string in 0..99, in order to return that, I must construct that result. That's the slow bit.
… I agree that's no extra work to recognize that a prefix matched, at least for an Earley parser, but constructing the result is.
Scribe observes that we have had some misunderstanding about what would be returned.
Steven: three options: 1, no extra state; 2, having the state and not specifying what goes in the body, and 3, having the state and requiring the prefix to be in the document.
Another attempt at a straw poll, which of those three options do you prefer:
Steven: personally, 3, but I could live with 2.
John: 2.
Norm: 2, or 1, but not 3.
Bethan: 2.
Michael: what I would prefer is that processors are allowed to do 3, and have a user option that allows the processor to return that value.
(Scribe observes that Michael's preferred wording is above)
Some discussion of how implementation defined this option should be.
Tom: Fine with 3 if it's optional, otherwise 2, 1, 3.
Consensus appears to form around the idea of 3 if it's optional.
ACTION: Steven to draft a concrete proposal for the spec using information from the straw poll. CG to review.
<cmsmcq> [MSM proposes to add a sentence to the final bullet item of the spec: "If the processor returns a parse tree for a proper prefix of the input, the ixml:state value 'prefix' (or kwd tbd) may be used to label the parse tree."
Media types
<Steven> https://
Steven: should we mention anything about the media type in the spec?
Steven: Creating a media type is a fair amount of work. We could use an x- media type. I'd prefer to use text/ over application/, but then you have to specify the encoding.
… there's a parameter on the media type that identifies the syntax.
Steven: I'm not sure it has to go in the spec because it's so time consuming.
Tom: We're conflating two things, media types that we can serve documents with so that they are parsed by an invisible XML processor and presented as xml, and the media type for invisible XML itself.
… Can we distinguish between "documents" and "grammars" for clarity in this discussion?
… If we're talking about the media type for documents, we can leave that out of 1.0.
Steven: The question of whether we wanted to create a media type for ixml grammars themselves wasn't strictly part of this question.
Michael: Your remarks about how time consuming it is to register a media type were persuasive to me. I think I agree, not in 1.0. But in the meantime, refresh my memory, what's the current status of using x- prefix.
Norm mumbles something about thinking they changed it.
Norm: I think we have consensus to mark this "v.next" and move on.
Some discussion of whether or not we should mention in the spec that we explicitly decided not to do this in 1.0.
Michael: I'm inclined to say it's an editorial question and ask the editor to do what he can.
What grammars should we accept (see agenda)
Michael: There are errors in grammars that are detected regardless of the input, and there's a separate class that are only required to be detected on input that exposes them. This fits slightly uncomfortably with the current language that says a conformant processor is supposed to accept conformant grammars and reject others. I'd like this to be clarified.
… as a discussion proposal, I'd say we distinguish two classes of errors, which we'll call "static" and "dynamic". In both cases, the formally, it is an error in the grammar and processors are required to detect static errors all the time, but they are allowed to detect dynamic errors only in the presence of input that raises them. But they are *allowed* to detect dynamic errors without any input.
Tom: I'm more than happy with the definitions of static and dynamic.
General agreement, though perhaps "dynamic" can be improved on.
Steven gives regrets for 8 March; John for 8 and 15 March.