Meeting minutes
<trackbot> Sorry, but no Tracker is associated with this channel.
Actions
ACTION (2021-08-005): Tom and MSM to come with a pragma proposal. [Done]
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION (2021-10-001): Steven to draft a mediatypes proposal (see
<trackbot> Sorry, but no Tracker is associated with this channel.
https://
ACTION (2021-12-001): Steven to add his tests to github [Done]
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION (2021-12-002): Michael to write test catalog for Steven's
<trackbot> Sorry, but no Tracker is associated with this channel.
tests [Done]
ACTION (2021-12-003): Steven to add strings proposal to spec [Done]
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION (2021-12-004): Steven implement the resolution for issue 19 [Done]
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION (2021-12-005): Steven implement resolution for issue 18 on XML
<trackbot> Sorry, but no Tracker is associated with this channel.
names. [Done]
Implementations
Norm: I'm writing my own parser
… ongoing
… results for next month
Steven: I added a command-line way of calling
Tom: JayParser not yet highly performant
Dave: What should we expect by June?
Tom: At least two
Norm: I will have an implementation by June
… integrated in XProc and Saxon
Michael: I have an implementation, not performant (yet).
… faster by June
… also planning Prolog version
Dave: What level confidence by June?
Michael: I am confident
Tom: Mine needs a rewrite, not sure if it will be ready by June
Steven: I'm confident with mine.
Dave: I am concerned with the stability of the spec for June release.
Pragmas proposal
Tom: We have spent some weeks on the proposal.
Michael: Basic requirement is that they say things to processors without interfering with other processors.
… Syntactically distinct. Some way for processors to recognise whether they are being addressed.
… Uses square brackets and namespaces.
<Steven> s/I US/Us/
Michael: Syntax is straightforward
Tom: We had an idea of using attributes for pragma data
Michael: Where do pragmas occur, and what do they mean?
… identifying what pragmas need to do sets a minimum requirement.
… I care about the XML representation of grammars, and so don't want pragmas to be wherever comments can be.
Steven: It sounds like this proposal is addressing use cases that should be separately addressed.
Michael: A pragma should be allowed to respond in any way it wants to pragmas, including stopping and starting a game.
Steven: I disagree.
Michael: I think you are right to be concerned.
…
… one of the things we want pragmas for is to provide a way to support functionality that hasn't been standardised.
… extension behaviour allows you to gain experience.
… conformance requirements mean that processors should be able to ignore all pragmas.
Dave: What should a non-pragma processor do with a pragma?
Michael: Not trip over them.
Steven: What would change if iso the [ we used for instance {! ?
Michael: It makes pragmas heavier.
Tom: I don't believe that should be a priority
Steven: I really don't like using the syntax for character sets for pragmas
Michael: For my use cases I want a single character for pragmas.
Norm: we could have two representations, a single character unicode, and a multicharacter ascii.
Tom: I would like ASCII
John: When you're presenting the pragma data to the processor, you're parsing the rules
… it's tempting to get structure inside the pragma.
… but maybe it should be up to the processor
… you can work with a reserved comment structure
… as long as you can nest
Dave: It smells like a pre-parse
John: I find a pragma in my namespace, I pick up the arguments, a string, I can recursively parse that string against my pragma grammar
Michael: I have presented the proposal; we want syntax distinct, we want namespaces
Steven: I don't see the conclusion
… also it seems a lot of mechanism for what I saw as a simple need
Norm: Question -- suppose you subtracted the QName stuff, and adding namespaces later.
Tom: I wouldn't support that
Tom: I want a namespace part
<Tom> Correction: I am not saying that we need a QName namespace part
<Tom> I am saying that we need some way of avoiding namespace collision
Steven: Namespace collision or pragma collision?
<Tom> Happy to hear an alternative proposal to XML namespaces!
<Tom> pragma collision
Michael: I don't think that allowing namespaces there is any degree of complication.
Bethan: The pragma communicates with the processor, does it have to understand the input or only serialise it?
Tom: If you mean writing to disc, no, but providing an XML representation, yes.
Bethan: so the use of a pragma implies changing the result of the parser.
Tom: It may
Michael: Not will.
Tom: Two issues so far: 1 - syntax (that's the easy one)
… 2 - issue of namespaces. There is a wider issue with this.
Steven: Namespaces is an issue that needs to be addressed separately, and I'm worried by making it a part of prgmas, we block future development before we've even thought about it.
Dave: A statement of belief is that we need to meet more often.
Tom: Weekly at this time?
Tom: maybe deal with namespaces first, or ask Steven to suggest an alternative.
ACTION: Dave to propose terminology to separate document inputs and outputs.
<trackbot> Sorry, but no Tracker is associated with this channel.