Meeting minutes
SP: No outstanding items.
SP: Pragmas
NDW: Time limit, 30 mins
Pragmas
<Steven> https://
ndw: Re summary I posted to list: Any agreement? To list, SP:
BTW: One at a time?
SP: Devil in the detail?
MSM: +1. Note concerns.
NDW: 1. What is a pragma.
SP: Prefer communicate with a processor
MSM: Extra grammatical.Outside.
NDW: Can reword.
JL: Pragmas are extra grammatical. Does not change input text...?
BTW: extra to grammar,
SP: Does it affect the grammar?
MSM: Can? I think 'extra grammatical' is to convey what can be conveyed. A syntactic sense.
<cmsmcq> Bethan: a pragma is nonconforming if it produces output you could not produce with a grammar without a pragma
<norm> Some processors will perform in ways that aren't conformant, no matter what we say. It's not worth worrying too much about.
BTW: ? Don't affect syntactic effect of an ixml rule.
TH: ?
SP: Pragmas can affect an ambiguous parse. Should not affect standard grammar operation
BTW: Need defn of a conformant pragma? Define behaviour.
JL: Behaviour related to syntax of pragma?
BTW: No. A grammar with those pragmas should not affect standard effect. Non conformant if grammar without that pragma couild not be produced with a grammar without that pragma.
TH: Could not process markdown.
<Tom> specifically embedded tags in markdown
MSM: Makes me nervous, conformance used as value judgement. Hence conformance for pragmas makes me nervous. E.g. make this change case?
SP: Are we changing ixml into a different process. Against this. Avoid what could be pre / post processing.
TH: Agree a potential for implementing in pragmas what should be ixml. If dealing with extensions. E.g. ns should be part of ixml. A june release, any reason why we should refrain from standard set of pragmas for later implementation.
MSM: Std pragmas are implemented elsewhere. SP still thinks pragma mech can do things which might be in spec.
MSM: 1. I don't think we have a choice how ppl use pragmas. 2. May be a serious lang design disagreement SP/MSM. qch wants to do a different thing(s), i.e. not in ixml. If we define functions, we can do it. If not fns, can extend the language. Algol 16(tbc) added io syntax. Pascal assumes implementations will extend syntax. So for some reasons, ppl want pragmas or similar so extensions are marked, so as to be ignored. In ixml 1.0 we want short and
simple. Others may want to provide extensions. We chose examples showing extensions which are not standardised. That's all. Real requirements.
DP: Can't get everything in 1.0..
<cmsmcq> [MSM observes that the existence of pragmas in XQuery has not seemed to have deleterious effects on interoperability in XQuery.]
<cmsmcq> TH: we all seem to mean different things by pragmas, and that's fine.
<cmsmcq> TH: the greater evil is not having any extension mechanism, rather than having none.
<cmsmcq> DP: If I look at XSLT 3.0 with lots of extensions, others can ignore the extension functions. Are pragmas a complete black box?
<cmsmcq> JL: The possible locations for extension functions and extension instructions in XSLT are fairly narrowly constrained.
<cmsmcq> JL: a pragmas proposal for ixml similarly seeks to guarantee that pragmas can be reliably identified.
MSM: SP response?
SP: Frightened by everything coming past. A dble edged sword. "legacy is for ever" See it as rubber stamping all sorts of stuff. If done in a comment, looks different.
TH: I dn't see pragmas as endorsing what they convey. Any pragma non conformant parse. Equally, if using comments, how is that less of a rubber stamp?
BTW: Don't see syntax that speaks to a processor vs pragma.
TH: Diff in values. Can't see how we can progress.
MSM: expand
TH: Fundemental diff in values. SP concern over scope / lack of control. Pragmas can means something diff for all of us. I agree. Either have an extension function or we don't.
DP: Could we see pragmas as a black box. "Implementation dependent"
JL: Analogy with xslt, there are constrictions. Limited in where they are (syntax), also effect limited in generating results. ixml trying to set similar constraints, part of grammar, hence can be parsed.
DP: Could we apply similar ideas in ixml?
TH: Two diff things. Yes can be constrained, we can't constrain effect of pragma.
SP: CSS added something similar (??), meant all processors were different.
BTW: Big diff CSS and ixml. Lot of impls, vs fewer with ixml. Hard to see becoming out of control.
<cmsmcq> DP: question for Steven: should we proceed with defining pragmas?
<cmsmcq> SP: I understood us to have agreed that the 1.0 language was done, except for correction of errors. But now we are doing design work, trying to add a new feature to the language.
<cmsmcq> At the beginning I thought pragmas looked like a good idea, but the more people talked about them the more they looked to me like a mess.
<cmsmcq> SP: What I had in mind was two lines in the spec. This is a pragma, it's a comment.
SP: That should not affect ixml today.
BTW: These are 'potential' use cases. Some should not be part of base ixml, e.g. optimisation, which can't be part of the grammar.
TH: I don't think it rare, not mandated.
DP: SP, do you support pragmas.
SP: Lang was semi frozen (chilled), then get to next version. Now doing design work, always gets messy. Adding new feature, takes time. At beginning yes, now less so.
<norm> If we're going to go this way, and I suspect I can live with it, I propose "{#" to start and just "}" to end. It is *just* a comment.
BTW: you wouldn't object to processor comments, but not if called pragmas and detailed part of spec.
SP: Anticipated two lines in spec.
BTW: If comments for processor, will need addnl syntax?
SP: Agree.
BTW: comments can be addressed to processor (X syntax), is that OK? Could others live with that. OK for V1
TH: Possibly. Still need a way to label, address nested pragmas. Interested in design choices that went wrong.
<Tom> And how this approach avoids those mistakes
<cmsmcq> [MSM does not see the point of such a provision.]
BTW: if others accept this simpler syntax.
NDW: Ok, acccept now, talk about it next week.
DP: ndw, btw post to list.
JL: Enough scope on comments (where allowed) If not
DP: JL, please post to list.
SP: Would like to talk about accepting whole input and media type.
MSM: CSS issue?
SP: Property names ???
<Tom> Thanks for minute taking, Dave!
<Steven> "Pragma" property names, specifically addressign a particular implementation