14:13:19 RRSAgent has joined #ixml 14:13:19 logging to https://www.w3.org/2022/05/24-ixml-irc 14:13:30 rrsagent, make logs public 14:13:42 Meeting: ixml Group Teleconference 14:13:53 Date: 24 May 2022 14:13:58 Chair: Steven 14:14:23 Previous meeting: https://www.w3.org/2022/05/17-ixml-minutes 14:14:51 Agenda: https://lists.w3.org/Archives/Public/public-ixml/2022May/0037 14:14:58 rrsagent, make minutes 14:14:58 I have made the request to generate https://www.w3.org/2022/05/24-ixml-minutes.html Steven 14:22:16 John has joined #ixml 14:28:50 norm has joined #ixml 14:32:43 Present: John, Bethan, Norm, Steven 14:36:23 Tom has joined #ixml 14:38:43 cmsmcq has joined #ixml 14:41:29 Present: +Michael 14:41:33 Present: +Tom 14:42:57 cmsmcq_ has joined #ixml 14:44:47 Scribe: Norm 14:46:10 Topic: Review of action items 14:46:33 Revert wording to attributes: completed 14:47:02 Add wording to forbid xmlns attributes: completed. 14:47:14 Steven: I note that this means we need new errors. 14:47:16 Norm: I'll do that. 14:47:59 Insert Michael's ambiguity text: completed. 14:48:09 Steven: I removed the remark about "sentences" and just talk about parses. 14:48:19 Contact Prague: completed, but have not heard anything. 14:48:35 Version declaration: completed, but we still need to discuss how exactly we want to do it. 14:49:11 Topic: Version declaration discussion 14:49:56 Steven: A grammar must conform to the syntax of the version declared or implied. 14:50:15 ... That's a new conformance requirement. 14:52:48 Some discussion of "must" with respect to producing a warning if the version declaration is not recognized. 14:53:23 Michael: In other cases, what we do for warnings is put attributes in the ixml namespace in the output. 14:53:40 ...Maybe add unrecognized version should be a value of state? 14:53:50 John: I think this depends on what the APIs of the processor are. 14:54:09 ...I'm not terribly happy that failure gets indicated in the output, but that's not really an issue. 14:54:28 ...There are potentially different channels. And we should require everything to go down that channel. 14:54:44 Bethan: The only thing that we can be certain of is that the spec specifies that you have to serialized as XML. 14:55:02 Some discussion of the ixml:state="fail" case for failed parses. 14:56:00 Michael: If you have other channels and want to produce output on them, that's okay. 14:56:49 ... 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. 14:57:32 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.) 14:57:48 Michael: I would want the information that the parser didn't recognize the version in any case. 14:57:59 Norm: I'm okay with that. 14:58:42 Some discussion of the case in the failure state. 14:59:25 Tom: Can I suggest that rather than reusing ixml:state, we have a second attribute? 14:59:37 ...That is only required when we don't recognize the version being used. 14:59:54 John: I like that. 15:00:34 Michael: Exploring Tom's suggestion of a separate attribute, I wonder what goes in it 15:01:16 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. 15:01:42 Bethan: If we just did ixml:version= and the version used, would that be enough? Given that'll match the version requested or not. 15:02:16 Steven: The problem is that you're not always going to be looking at the output. 15:02:54 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. 15:03:09 ... I thought I was asking for 23, why did you think you couldn't parse 2.3? 15:03:36 Norm: All we say is that you should put useful information the error document. 15:04:04 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. 15:04:35 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. 15:05:09 ... 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. 15:05:50 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. 15:06:15 ... 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. 15:06:33 Michael: I agree with everyone that says it may be more important in the case of success than in failure. 15:06:49 ... But in general, if a precondition wasn't satisfied, it's relevant no matter what. 15:07:53 ... 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. 15:08:03 ... I think everything else is useful and good processors will provide it. 15:08:24 Bethan: I see the point about using it in state, but what about ixml:version-missmatch="requested used" ? 15:08:43 ... That would mean an extra attribute, but it would be more informative than just a single token. 15:10:15 Norm: I support simpler. Just a single token. 15:10:26 Tom: Maybe in v.Next we can do more. 15:10:42 Proposal: Add a new token to the ixml:state attribute, "version-mismatch". 15:10:43 Accepted. 15:11:27 Discussion of or 15:12:41 Some discussion of why all the values are in attributes. 15:13:24 ACTION: Steven to rewrite the prolog syntax to support containing 15:14:42 ACTION: Steven to rewrite prolog to deal with the warning 15:15:00 Topic: Issue 83, tmark on charsets 15:15:03 Some discussion of the typo. 15:15:23 John: Does it make sense to have another mark for charset so that "+" can't appear? 15:16:37 Norm attempts to clarify that (he thought) John was referring to adding a cmark that didn't include "+" 15:16:43 Michael: I think I'd prefer that. 15:17:16 Steven: I pointed out recently that actually an insertion is a completely different beast. 15:17:50 An insertion should be a new kind of terminal. 15:17:54 Michael: I think that makes sense. 15:18:49 ACTION: Steven to change insertions into a new kind of literal instead of a mark 15:19:00 Topic: Release planning 15:20:52 Norm: If you get us a draft, we'll review it for editorial changes for next week. 15:21:14 ... We should agree that the draft next week is the 1.0 draft. 15:21:41 ... Everyone should raise issues for anything they'd like changed on the home page for the release announcements 15:21:52 ACTION: Steven to try to reach Jirka directly re: Prague 15:22:04 rrsagent, draft minutes 15:22:04 I have made the request to generate https://www.w3.org/2022/05/24-ixml-minutes.html norm 15:22:28 Adjourned. 15:23:48 Present: Tom, Norm, Michael, Bethan, Norm, Steven, John 15:24:19 ACTION: Norm add new conformance errors for well-fomed text 15:25:56 rrsagent, make minutes 15:25:56 I have made the request to generate https://www.w3.org/2022/05/24-ixml-minutes.html Steven