– DRAFT –
ixml Group Teleconference

Review of agenda

[No comments][

Previous Actions

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

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

Steven: I did draft a reply; should go on a future agenda

ACTION (2022-01-001): Dave Pawson to propose terminology to separate

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

document inputs and outputs.

Dave: I have updated it with everyone's comments.
… an issue will still be replied to
… I believe the action is complete

Issues

MSM: I would like to handle some issues, so can we time-box something before talking about pragmas, or vice versa

Tom: to top of hour
… discussing issues

issue #27 Should ixml elide the difference between dstring and sstring?

https://github.com/invisibleXML/ixml/issues/27

RESOLUTION: Remove the difference between dstring and sstring

issue #5 Whitespace / comments in awkward places

https://github.com/invisibleXML/ixml/issues/5

MSM: I reopened an old issue of Tom's.
… eg a comment in the middle of a range

Steven: Oh yes, a bug in the grammar, and I believe it is now fixed.
… I will commit with a comment

John: where does the comment end up?

MSM: Now in the attribute, shortly in the XML.

issue #22 Clarify the spec by making "empty" more explicit

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

Norm: as a new user, I missed the empty alternatives.

MSM: Either () or nonterminal, "empty".

Steven: I can live with that.

ACTION: Steven: make empty visible in the ixml grammar

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

ACTION: Steven: Commit new version

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

issue #24 Does ixml have to match the whole input?

https://github.com/invisibleXML/ixml/issues/24

Steven: How about the proposal of a state that says we have found a parse, but with leftover input.

Norm: I'm not sure I can support that.

Dave: I think it should be a fail if there is input left over.

Steven: An example case is if there is a trailing newline that the grammar doesn't accept.

MSM:

<Tom_> Michael proposes that the spec says an implmentation

MSM: the spec should say the processor may add user option to allow the consumption of a prefix of the input.

<Tom_> MAY allow the user to specify a mode where it parses the largest possible prefix of the input

John: With a streaming input, with repeats of the same, it would be helpful

Tom: streaming would be ice

MSM: Not as easy as you think

Tom: I would like to rely on the grammar to tell me where the end of the input is.

Norm: Leave the status quo, and spec it later.

MSM: We need to decide whether to mention it or not.

Steven: I have an example of a URL that ends with a # part, but the grammar doesn't specify the hash part.
… is that a fail, or a match with left-over input?

Dave: A fail.

Bethan: I like having an option.

Tom: I agree.

Steven: The advantage of a state is that it means the user can decide if it is a fail or not.

MSM: a* vs "aaa".

Bethan: You should stop when you've reached a point where you can't parse any more.

Pragmas proposal

<bethan> (but you should not stop unless you cannot consume any more of the input)

Tom: For good reasons or bad, we aren't talking about just pragmas, but entangled them with namespaces.
… we haven't reached consensus on whether namespaces should be in v1.

John: Any work on pragmas will have to disambiguate pragmas

Norm: If you accept that pragmas doesn't deal with disambiguation, there is no need for namespaces.

Tom: Legacy is forever
… We need to decide whether to disambiguate.
… Then how to do it.

John: Regardless of pragmas, I believe we will need namespaces in v1.

Steven: It wasn't in the original requirements, in fact it was an anti-requirement

John: But what if you want to produce SVG mixed with something.

Steven: Post-process
… XML is only one of the possible targets.

Tom: I understand Steven's argument and agree with it up to a point.
… the extent of that argument is remove attributes.

C. M. Sperberg-McQueen17:11

Sometimes I wonder if Steven is unconsciously slipping from "it is not a requirement to do X" to "it is a requirement that we not do X". I think John's remark illustrates the point that users will have their own ideas about our requirements.

Dave: Can the two issues be separated, the use of SVG in HTML and pragma disambiguation

Dave: 1) Accept namespaces.

Steven: It's not as easy as that

Tom: Or as clear-cut

Tom: We have a pragma proposal

MSM: Can you expound on where you think the complications are?
… I believe a syntax that allows definition of namespaces, then we can produce namespaced XML, and everything is straightforward.
… it seems to be simple enough.

Steven: I don't think it's as easy as you think. Design takes time.

Tom: I wonder what objections you have to the existing proposal.

Steven: I said those last week.

Bethan: The only thing that comes in are namespaces and pragmas.
… can we attempt to say let us act as though we do want namespaces and see whether it works.

Steven: No objection to that.

Bethan: ...
… maybe we can satisfy everyone.
… I like the pragmas proposal.

<Tom_> Michael: Those comments apply to the pragmas proposal, but not visibly to the part of the proposal that addresses namespaces. And the syntax of namespace declarations is explicitly mentioned as something that the CG could change, so I don't understand "I don't like the syntax chosen" as an argument. Propose a new syntax for namespace declarations, then?

<Tom_> ("Those comments" meaning "what Steven just said, summarizing his objections")

Dave: Question for MSM and Tom, do you have pragmas and namespace inclusion?

Tom: Yes.

Dave: Then that answers Bethan's point.

Tom: The pragma proposal addresses the namespace issue.

MSM: Those of us who think that there is a namespaces solution outside of pragmas should propose that.

Dave: Is that sensible?

MSM: I believe that pragmas make sense only with QNames
… which is why we proposed what we did
… but namespaces don't require pragmas. Maybe separating them might be advantageous.

Norm: There are a lot of weighty issues around these two topics. Let us focus on the syntax next week.
… If we could start agreeing on strings it might help.

[ADJOURN]

ACTION: Steven: remove dstring and sstring differentiation from grammar

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

<Steven> s/… maybe we can satisfy everyone./Bethan: maybe we can satisfy everyone./

<Steven> i/… maybe we can satisfy everyone./Bethan: .../

<dpawson> finally!