W3C

– DRAFT –
Invisible XML CG group call

13 September 2022

Attendees

Present
Bethan, John, Michael, Norm, Steven
Regrets
+Tomos, Tomos
Chair
Steven
Scribe
Norm

Meeting minutes

Review of action items

Steven had an action to update the community web page, which he has.

Status reports

Steven: The big news from me is discovering that I could do Unicode. Was also able to delight other ABC users by showing them how to use Unicode

Steven: I'm also writing my advanced iXML tutorial for Declarative Amsterdam (in November)

John: I basically updated my workbench so that you can re-load local files. Working on drag-and-drop.

John: And I've implemented "recordization".

Norm: Yes, I think "recordization" is the only new thing I've done. You can break a file on regular expressions.

Michael: I've been preparing to work on performance by putting together some test examples and trying to make the parser run in additional XQuery engines.

Michael: I've been working on getting it work in eXist DB and filing bug reports. Hoping to come back to it. Will try to make it work with Saxon HE. And then, performance!

Status of implementations

Status of testing and test suites

Norm: There's an outstanding PR for a new set of test results that I'd like approval for.

Michael: One topic that's related to the test suite, is that since some of the test cases have an infinite number of parse trees, the fact that the test catalog simply lists a finite number of them works fine for parsers that produce trees deterministically.
… It's a little more tedious when the trees change, or when your choice of trees is not deterministic. For some test cases, the probability that the tree chosen will be one of the trees listed converges to zero.

(Some discussion of ambiguity; if you want a particular tree, rewrite your grammar so that it's not ambigous!)

Michael: We could provide schemas for some of the test cases that would offer some confirmation.

Norm: Is conforming to the schema a guarantee that the test passes?

Michael: Some of them, but not all of them.

John: Some of this seems to be impractical; we're spending a lot of time on problems that probably will never occur. Or maybe they will.

Norm: On a small tangent, some BNF translations of EBNF may be faster than others. Michael pointed out that we could reformulate some in iXML simply without using the EBNF features of iXML. That might be worth doing.

Michael: Minimizing the number of non-terminals may produce better results in Earley, for example.

John: That's very true of the rewrites that Bethan proposed. That got rid of one non-terminal for ever repretition. That made a huge difference.

John: I got a performance improvement of about 8 minutes for the whole test suite down to just over a minute. I'll try to do some more investigation.

ACTION: Norm to finish his document about EBNF to BNF translation

ACTION: John to report how many Earley items are reduced by the changed rewrite rules.

Status of Balisage paper

Steven: I'd like to amend my section to discuss the fact that I can now do Unicode.

Michael: It's a bit late, but if you can do it this week...

Norm: We have a master DocBook document that Bethan produced for us.

Micheal: I'll wait to see that Steven's changes have come in and I'll nag to get them in.

Michael: If I have time, I'll make one more copy-editing pass. Steven will mention Unicode and then I'll get it in.

Review, discussion, resolution of issues

Steven: One issue is the errata document.
… we know there's an issue, how shall we fix it?

Some discussion of the issue, there's a Unicode class that's "LC".

John: You have to check that it's a proper class, but I see no reason to add "LC".

Steven: We don't normatively reference a particular version of Unicode, so there could be more.

Norm: On that basis, I prefer letter-letter.

Michael: Do we have a guarantee that it'll be two letters?

General consensus is that it will remain two characters, just because the entire database is built in a way that shows a little bit of awareness of compactness issues and so forth.

Michael: I like letter-letter.

Steven: The first letter is always a capital, so do we say capital letter, letter?

Norm: I think I like capital letter, letter.

ACTION: Norm to edit the 1.0 spec "in place" to add the errata document link

ACTION: Steve to draft text (in HTML) to resolve the erratum.

Issue #145, https://github.com/invisibleXML/ixml/issues/145 the process issue is #142, https://github.com/invisibleXML/ixml/issues/142

Issue #138, arrange for ixml.xml to be downloaded not displayed in a browser

Michael: Some of us seem to be discussing ixml.xml which is what I raised the issue about and some of us are discussing ixml.ixml. I propose that we try to clarify what we would like to happen with both of them.

Norm: I think ixml.ixml (DOT IXML) always downloads.

Bethan: I'd prefer to have that display as text and have an option to download something.

Michael: I'm a little confused because what I see when I see (in Firefox on Linux) is an XML display.

Bethan: What you get in Safari is an attempt to render that as HTML.

Norm observes that it's served as 'application/xml'

Bethan: I think making it work on Safari is also fairly useful.

Norm: I think we can tell browsers to download the document.

Michael: We could add a stylesheet PI. That would cause browsers to display it.

Some discussion of what behavior is desirable.

Norm: I thought making it always download was easy and consistent.

Bethan: I think both links should do the same thing.
… I think the best option would be to have the content displayed with a link that lets you download it.

John: The other possibility is that we push the problem off to github.

Bethan: Not everyone is comfortable with GitHub. Having pages that display the ixml and xml shouldn't be hard.

Norm: I could certainly live with that.

John: And would the display effectively be just a PRE or would it be syntax highlighted?

Bethan: I think a bit of syntax highlighting is nice. Making elements collapsible would also be nice as Steven suggested.

Michael: I don't remember this download instead of display behavior that I used Safari.

John: Can we leave this for another week?

Steven: I think that on the page we could have a "download" link: "available in ixml [download] or xml [download]"

ACTION: Norm to try out the stylesheet PI trick on the XML version

ACTION: Norm to create an issue for the question of control characters in ixml grammars

Process for handling errata (issue #142)

Michael: Shall we adopt the proposal in #142?

Assent all around.

Norm: I'll implement it when I do my action listed above.

Next meeting

Next meeting is 11 October 2022.

Scribe for next meeting is John; failing John then Steven.

Adjourned.

ACTION: Steven to update the meeting starting time on the community group page.

Summary of action items

  1. Norm to finish his document about EBNF to BNF translation
  2. John to report how many Earley items are reduced by the changed rewrite rules.
  3. Norm to edit the 1.0 spec "in place" to add the errata document link
  4. Steve to draft text (in HTML) to resolve the erratum.
  5. Norm to try out the stylesheet PI trick on the XML version
  6. Norm to create an issue for the question of control characters in ixml grammars
  7. Steven to update the meeting starting time on the community group page.
Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).

Diagnostics

Maybe present: Micheal