Minutes ixml call 2020-12-17

Agenda 2020-12-17


Previous Actions
Website
Namespace
Specification
Implementations
Test Suite
AOB
Next call

Present: J, M, S, T.

PREVIOUS ACTIONS

ACTION: Steven to specify what happens when a name isn't an XML name
[Continues]
ACTION: Steven to research where to put S for attributes.
[Continues]
[ACTION: Steven to start a github org and admins]
[Done]
NEW ACTION: Steven to add John
[ACTION: Tom to set up github pages]
[Done]
[ACTION: Tom to point the DNS to the github]
[Done]
NEW ACTION: Steven update the readme.md

WEBSITE/GITHUB/NAMESPACE

invisiblexml.org/NS

Steven: How do we create a subpage?

Tom: We can create a website in a directory.
... just pop it into the repository
... we can also do it in a more complex way

ACTION: Steven to create the Namespace document

SPECIFICATION
[no discussion]


IMPLEMENTATIONS

Tom: I have done nothing this month...
John: I got Tomos's implementation running. It ran out of stack space, but 
it is running.

TEST SUITE

M: Working on automatic production of test cases. I want to generate
both +ve tests that provide good coverage, and a number of -ve tests
that also provide coverage.

Steven: That latter is harder to define.

M: I want a grammar for a regular language, a superset of the target
language, a reasonably good approximation of the target language, take
the FSA, invert it so that accept becomes reject and VV, with an error
state that becomes accept, and generate +ve tests for that
grammar. For every arc, I want a test with that arc as the final arc.

Steven: What I did was recursively walk the grammar, selecting alternatives 
at random...

M: Or generating one of each...

Steven: and then to generate -ve tests by adding <empty> at every set of 
alternatives.

M: Problem is, that can also produce +ve tests.

S: and you'd like to guarantee they are -ve. I see.

M: But I have made progress. I have a 100 character regular expression
of <statement> from the example grammar that doesn't take account of
matching brackets.

Steven: Should we be putting the tests on the github? ... though we
haven't agreed on a format yet.

M: We should put them up, and once we have the sense that the
catalogue is enough, we should agree then a format.

T: In the long run, we should do it in ixml.

J: So we have a grammar, a number of example inputs, with equivalent
outputs. The bigger bit is the sample grammars. Does that grammar
compile, and does the result of that respond to the test cases. A two
level arrangement 'environment' and 'test cases'. What are you trying to 
test?

T: Defining what the 'features' of ixml grammars are is already
hairy. But the failure cases are possibly even harder.

M: There aren't additional restrictions on ixml grammars except
syntax. Q1 is this an ixml grammar? Q2 is the input a string in the
language? Q3 is the parsetree the correct one? For unambiguous
grammars, the result is deterministic. For ambiguous grammars...

T: If you roundtrip it twice, and at the end of each roundtrip is the same 
...

S: The serialisation of a parsetree is not guaranteed to be acceptable
to the originating grammar a second time.

J: In the tests, does the parsetree matter?

M: I could write a universal grammar, which would accept any string,
but not produce the required parsetree.

S: Should we put the tests on the github?

T: Are we ready?

M: We should put the tests up but not in the central repo, but in
individual ones. Later we can merge and put in the central repo.

T: We also need to divide the tests into classes on the basis of which
part of the process they are attempting to test.

M: 3 classes of test case. 1 is it an ixml grammar; 2. it is, plus a
valid input, 3. it is, plus an invalid input.

T: We need a vocabulary for producing error messages for users.

S: Errors for an ixml grammar are easier than for the input to that
grammar. There's not much more than "I was expecting one of these
characters at this point" ..."

T: I don't want my system to need to check that the XML form of an
ixml grammar is a correct ixml grammar.

M: Shouldn;t be a problem.

AOB

Next call
Thursday 2021-01-28, 1500Z
https://meet.google.com/dfz-rwpj-opq

Actions
ACTION: Steven to specify what happens when a name isn't an XML name
[Continues]
ACTION: Steven to research where to put S for attributes.
[Continues]
ACTION: Steven to add John to org
ACTION: Steven update the readme.md
ACTION: Steven to create the Namespace document
#end