W3C

– DRAFT –
ixml meeting

25 January 2022

Attendees

Present
Bethan, Dave, John, Michael, Norm, Steven, Tomos
Regrets
-
Chair
Steven
Scribe
Steven

Meeting minutes

https://lists.w3.org/Archives/Public/public-ixml/2022Jan/0140.html

https://lists.w3.org/Archives/Public/public-ixml/2022Jan/0140.html

Action items

ACTION (2021-10-001): Steven to draft a mediatypes proposal (see

https://github.com/invisibleXML/ixml/issues/6). (Pending discussion.)

<trackbot> Sorry, but no Tracker is associated with this channel.

Steven: An agenda item today

ACTION (2022-01-002): Steven to make empty visible in ixml grammar

https://github.com/invisibleXML/ixml/issues/22).

<trackbot> Sorry, but no Tracker is associated with this channel.

Steven: Done and closed

ACTION (2022-01-003): Steven to remove dstring/sstring differentiation

<trackbot> Sorry, but no Tracker is associated with this channel.

from grammar.

Done and closed

ACTION (2022-01-004): Steven to commit new draft spec.

<trackbot> Sorry, but no Tracker is associated with this channel.

Steven: Done (three of four times)

trackbot, leave

Pragmas proposal

Norm: Syntax
… a contingent wants syntax distinct to comments, and some think that they are a flavour of comment

Steven: I feel pragmas are a form of comment

Norm: I like them having a different syntax

Dave: I don''t see them as related to comments at all.

<norm> They aren't comments and a pre-processor that discarded comments shouldn't discard them, for example.

Steven: I think if there are people who don't see them as comments, then we don't agree on what pragmas are.

Tomos: My prefernce is for them not to be comments. A pragma is an instruction that may be ignored, but it defines some data that a processor can understand and act on. We are being deliberate in not defining what pragmas do.

Steven: I disagree.
… with that last sentence.

Bethan: The distinction is that a comment is purely meant to be human readable, and pragmas are the opposite.

Tomos: As comments, a non pragma processor has to do nothing.
… But then we have no control on the structure of pragmas.

Steven: Disagree.

Michael: Steven's strawman shows that you can define internal structure.
… I believe they need to be distinct.
… if we want them to be lightweight, insisting that they have a distinct delimiter, and I want a single character

John: If you are the processor and you are handling pragmas., you need to see if you understand that pragma, then I parse it consequently, and then can then act on it, wherever in the tree it is.
… the question seems to be if that is lightweight enough.

Dave: I disagree.
… Pragmas may affect the input ixml, or the grammar.

John: The pragma could do a tree rewrite. I have taken in the ixml which I look at and find a comment at the appropriate point.
… and then I can do some rewriting.

Steven: My strawman shows that you still get the tree you want.

Michael: I parse and get the tree. If there are pragmas, and they indicate that there are other things I should do, which may involve modifying the internal representation of the grammar.
… I think of pragmas as a form of annotation.

Norm: Whatever syntax we use, it is possible to see them during parsing.

John: javascript...

Norm: No! They messed it up. We want to do it right.
… we need to decide on syntax.

Michael: To answer your question, is yes if we agree.

Dave: We had a good argument last week, on why they are important for the first release.

Bethan: Let's stick to the syntax of pragmas.

Tomos: The root of the problem is whether pragmas are comments or not.

Norm: There are 3 different categories here: 1. Pragma is (<cha> 2. "[" starts a pragma 3. Other pair of characters.

Steven: Should pragmas be nestable?

Michael: Delicate.
… yes and no
… if we have a delimeter pair, then they should next
… I assume that we have use cases of nested pragmas.
… On the other hand it is a technical error to have recursive pragmas in the grammar.
… there is no guarantee that the syntax for pragmas will use the pragma symbols for pragmas.
… I don't want comments and pragmas to be recognised by the ixml parser within pragmas.

Bethan: if we have a syntax, we can at least discuss them.
… I think that while whatever symbols we use to start and end a pragma, they should mark a pragma in th a pragma.
… is what Michael said

Michael: In Steven's strawman pragma rewrites, means that when I parse a pragma, I have to look inside, to see what it is.
… so the content is not unconstrained.
… I think the prose in his strawman is right, but the grammar not.
… In our alternative is to define pragma as containing strings containing pairs of left delim right delim and other stuff.
… but these are not nonterminals.
… I can match the close delim, because I can match the contained pairs

Steven: That's not an argument against my strawman. I was only trying to show you can use comment symbols for pragmas.

Norm: Back to where we were, modulo of nesting.

Michael: Steven is opposed to square brackets. I am happy to drop that as syntax.

Norm: That simplifies it!

Dave: Also drop the comment as pragma delimiter

Michael: I think Steven has explained the advantage of having strings with {} and nested as a class and using them as pragmas, but do you see a problem with using other characters?

Michael: I want the start and end to be symmetric.

Bethan: If I am a processor, and I see a comment and I ignore it.
… If I as a human write my fgrammar, and a pragma, consists of a { and a character, if I omit the character, the processor thinks it has a comment. A pragma with a different character gives an error.

Steven: You'll see you didn't get the result you wanted.

Bethan: That's debugging.
… so I think a different character is better

Tomos: You believe that pragmas are comments
… that's the same as Brexit is Brexit.
… A comment is prose for humans.

<dpawson> SP: Semantics of pragmas is zero.

<dpawson> TH: Pragmas are comments - I struggle with this. Why are they the same. I see comments for people, pragmas for processor.

<dpawson> TH: Why can't we distinguish them?

<dpawson> SP: I see I'm in a minority.

<dpawson> TH: What is belief or with supporting reasoning.

<dpawson> SP: Why a different character / delim.

<dpawson> TH: Have to ignore a comment, why not others

<dpawson> MSM: They will do something diff, comment to pragma.

Bethan: Some of us believe that comments are for humans, and pragmas for processor.

Steven: I don't accept that distinction.

John: When I made remarks about other languages that screws things up

Norm: I'm a tiny bit in agreement with Steven's remark that processors that want to ignore pragmas can do that.
… if the syntax is as comments.

Norm: I propose that we discuss next week what pragmas are for,.

Steven: I agree that that is an underlying problem.

Norm: See my issue on github

Tomos: That needs to take into account our usecases.
… Can I propose a change
… Dave could you minute it next week.

Dave: Agree.
… Can you put links on to the list for the issue and proposal that we need to look at.

<norm> The issue I mentioned is, https://github.com/invisibleXML/ixml/issues/29

Bethan: Are pragmas like processing instructions?

Michael: ixml can't generate processing instructions.
… we want to add that
… I am happy with comment elements.

[ADJOURN]

<dpawson> SP: Can forward my notes if you can make use of them.

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/;/'/

Succeeded: s/;/'/

Succeeded: s/parg/prag/

Succeeded: s/Michael/Michael:/

Succeeded: s/I f/If/

Succeeded: s/;/'/

Succeeded: s/I /Are /

Succeeded: i/ACTION (2021-10-001): Steven to draft a mediatypes proposal/Topic: Action items/

No scribenick or scribe found. Guessed: Steven