14:42:05 <RRSAgent> RRSAgent has joined #ixml
14:42:05 <RRSAgent> logging to https://www.w3.org/2021/04/13-ixml-irc
14:42:53 <Steven> trackbot, help
14:42:53 <trackbot> Please see <http://www.w3.org/2005/06/tracker/irc> for help.
14:47:12 <Steven> RRSAgent, make logs public
14:47:33 <Steven> Meeting: Ixml Users Community Group Teleconference
14:47:52 <Steven> Date: 13 April 2021
14:48:26 <Steven> Agenda: https://lists.w3.org/Archives/Public/public-ixml/2021Apr/0008
14:50:14 <Steven> Steven has changed the topic to: Meeting at https://meet.google.com/dfz-rwpj-opq
14:52:01 <Steven> Chair: Steven
14:52:12 <Steven> rrsagent, make minutes
14:52:12 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-ixml-minutes.html Steven
14:58:11 <Steven_> Steven_ has joined #ixml
15:00:33 <johnLumely> johnLumely has joined #ixml
15:01:29 <johnLumley> johnLumley has joined #ixml
15:02:09 <Steven> Present: StevenPemberton, JohnLumley, AlekseiGusev, MichaelSperbergMcQueen
15:06:42 <Steven> Topic: Introductions
15:06:42 <Steven> [A quick round of introductions]
15:07:43 <cmsmcq> cmsmcq has joined #ixml
15:09:26 <Steven> Alexsei: I've worked with similar systems to ixml. I am based in St Petersburg, Russia.
15:09:55 <Steven> ... I will be updating my system to isml, to bring it to .net and C++
15:10:37 <Steven> cmsmcq: Will I know the formats you have processed before?
15:10:50 <Steven> Aleksei: It was one in Xerox.
15:10:58 <Steven> s/Alex/Alek/
15:11:45 <Steven> rrsagent, make minutes
15:11:45 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-ixml-minutes.html Steven
15:13:18 <Steven> cmsmcq: Involved with SGML about 30 years ago, then XML, worked at W3C for 10 years, now independent consultant. Interested in ixml because I like parsers.
15:14:27 <Steven> John: Recently retired from Saxonica, developing parsetrees for XPath expressions, making small parsetrees. I ended up doing parsetree reduction, eliminating parents with a single child
15:15:11 <Steven> Topic: Previous Actions
15:15:11 <Steven> ACTION: Steven to specify what happens when a name isn't an XML name
15:15:11 <trackbot> Sorry, but no Tracker is associated with this channel.
15:15:26 <Steven> [Continues]
15:15:35 <Steven> [Done]
15:15:46 <Steven> ACTION: Steven to research where to put S for attributes.
15:15:46 <trackbot> Sorry, but no Tracker is associated with this channel.
15:15:49 <Steven> [Continues]
15:15:57 <Steven> ACTION: Steven create W3C Community Group [Done]
15:15:57 <trackbot> Sorry, but no Tracker is associated with this channel.
15:16:08 <Steven> Topic: New draft
15:16:08 <Steven> https://lists.w3.org/Archives/Public/public-ixml/2021Apr/0005
15:16:48 <Steven> Steven: Includes a conformance section.
15:17:06 <Steven> ACTION: Michael to comment on confrmance section of new draft
15:17:06 <trackbot> Sorry, but no Tracker is associated with this channel.
15:17:40 <Steven> Topic: Requirement that input be completely consumed
15:17:40 <Steven> https://lists.w3.org/Archives/Public/public-ixml/2021Apr/0007
15:18:32 <Steven> Michael: THe problem is with streaming
15:18:39 <Steven> s/THe/
15:19:07 <Steven> Michael: "The longest string that matches"
15:19:16 <Steven> Steven: That's OK, that's the same thing.
15:21:00 <Steven> Aleksei: You may have an XML fragment with no root element. And then a stream of them.
15:21:20 <Steven> John: What happens if your input stream is a sequence of documents.
15:21:39 <Steven> s/documents./documents?/
15:22:11 <Steven> Aleksei: There are points in the input when you are certain.
15:22:15 <Tomos> Tomos has joined #ixml
15:22:43 <Steven> Steven: Not in the general case.
15:23:52 <Steven> Michael: You can do reductions at all points there's a match.
15:24:18 <Steven> ... I realise that might give an infinite number of reductions.
15:24:40 <Steven> ... Suppose I use ixml to make an ixml parser.
15:25:01 <Steven> ...  then I can repeat over the rules.
15:25:28 <Steven> ... So i believe there are two use cases for not requiring consuming the longest string.
15:25:49 <Steven> ... Prolog style (see email, and transient streams.
15:26:00 <Steven> Present+TomosHillman
15:26:31 <Steven> Tomos: Because we allow ambiguity, can be do ixml in streaming mode?
15:26:38 <Steven> Michael: I believe so.
15:26:59 <Steven> rrsagent, make minutes
15:26:59 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-ixml-minutes.html Steven
15:27:46 <Steven> Tomos: Big memory requirements
15:29:16 <Steven> Michael: The spec doesn't constrain how the result is produced.
15:32:49 <Steven> Steven: I would be extremely cross if I offered a document, and got an empty XML document just because it matched the initial empty string.
15:33:57 <Steven> Michael: If the ixml spec requires the entire input, it wouldn't work for streaming.
15:35:29 <Steven> Steven: It depends on the meaning of "entire input".
15:35:48 <Steven> ... that's the conformance requirement I'm looking for.
15:41:48 <Steven> Steven: A wording that supports the obvious case without excluding streaming is what I am looking for.
15:43:39 <Steven> Tomos: We have a default for parses that an implementation has to pick, we don't define those in the spec, but it would be useful to define how to deal with an ambiguous parse.
15:44:28 <Steven> John: You would have to be able to insist that the implementation gives you the biggest parse, if it were a choice.
15:44:59 <Steven> Tomos: That should be the default.
15:46:19 <Steven> Aleksei: Can't you just do greedy, like with regexp?
15:46:22 <cmsmcq> Aleksei:  you could define this in the same way as requiring regular expression parsers to be greedy.
15:46:46 <Steven> Steven: This would mean that parsing stops at an error, and says that the parse is correct.
15:50:05 <Steven> Tomos: How about when you find an error, providing a partial parse, and the rest of the input
15:50:24 <Steven> Steven: The spec already says that. We need to specify what happens for a correct parse.
15:50:43 <Steven> Tomos: Can't we just say "greedy" as Aleksei proposed.
15:50:53 <Steven> Steven: I think that that may work.
15:53:27 <cmsmcq> How close does this wording come to matching what people want?
15:53:31 <cmsmcq> In the normal case, the input will have a deterministic length, either
15:53:32 <cmsmcq> known in advance or signaled by some end-of-stream signal.
15:53:33 <cmsmcq> In that case, the default behavior of an ixml parser shall be to parse
15:53:35 <cmsmcq> the input as a whole against the grammar, and return a parse or a
15:53:36 <cmsmcq> failure document as described elsewhere.
15:53:38 <cmsmcq> Parsers may also support the case of input of non-deterministic
15:53:39 <cmsmcq> length, by parsing successive prefixes of the input.
15:53:40 <cmsmcq> Parsers may also offer, at user option, to parse prefixes of the input
15:53:41 <cmsmcq> even if the input has deterministic length.
15:53:44 <Steven> Aleksei: Greediness by default, because of the empty string case. But with streaming, there is an extra case.
15:54:39 <johnLumley> seems appropriate Michael...
15:56:56 <Steven> Michael: I don't want an interface that offers an infinite number of parses.
15:57:56 <Steven> Topic: AOB
15:58:05 <Steven> Next meeting Tuesday 11th mail.
15:58:14 <Steven> Further discussion on email.
15:59:07 <Steven> Tom: Namespaces on the agenda next month please
15:59:14 <Steven> rrsagent, make minutes
15:59:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-ixml-minutes.html Steven
16:03:07 <Steven> s/11th mail/11th May/
16:03:10 <Steven> rrsagent, make minutes
16:03:10 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-ixml-minutes.html Steven
16:05:08 <liam> liam has joined #ixml
16:05:51 <Tomos> Tomos has left #ixml