Re: Pragma Proposal ready for review

Many thanks, Dave.  Your reactions are very helpful.

Comments inline.

-Michael


> On 14,Dec2021, at 2:05 AM, Dave Pawson <dave.pawson@gmail.com>
> wrote:

> Comments on pragmas document.

> 2021-12-14

> # Pragmas

> [ref
> doc](https://github.com/invisibleXML/ixml/blob/proposal-pragmas/misc/pragmas.md)
> 13 Dec 2021 revision

> Comments, Dave Pawson.

> (Potential) issue, circularity? A mods B mods A? Can this be
> addressed?

I believe (a) you are right that there is at least a potential
circularity, and (b) that Tom and I found a way to bootstrap things so
that circularity is avoided.

> Namespace declarations: Applicability (xml rules apply?), how is
> scope related to the generated XML?

The proposal before us allows namespace declarations only before the
first rule of the grammar, which has the consequence that they apply
throughout the grammar and thus throughout the generated XML.

> At what point is ixml validation 'assumed'? Post pragma application?
> Where stated?

Not stated explicitly.  Since the effect of pragma application is not
defined, we cannot define the shape of a grammar after pragma
application, and the grammar in the spec defines the grammar with
pragmas in place, not whatever one ends up with after applying a
pragma (in cases where the phrase "applying a pragma" has a clear
meaning, which it won't always have).

> "Some of these use cases seem most naturally handled by annotations
> which apply to a grammar as a whole, some by annotations which apply
> to individual rules, and some by annotations which apply to
> individual symbols in the grammar."  I don't find this clear, I
> don't understand its implication.

I hope the examples made it clearer.

All it means is that if you ask "what does this pragma do?" the
natural-language answer will in some cases say that it does this or
that to a particular occurrence of a symbol, or to one particular
rule, or to the grammar as a whole.  My instinct is to think that it
is helpful to be clear on which it is -- in XQuery annotations and
extension expression, for example, it is always clear what expression
is being annotated or modified by extension.

> Is the 'fallback' action(expression) implementable? If a processor
> fails to 'understand' a pragma? Is it the same action expected of
> every pragma not understood?

The fallback expression is the expression modified by / annoted by the
pragma, and the fallback processing is to process the grammar as if
the pragma were not present, so yes, I think it's always
implementable.

> 3rd desiderata: Superficially this would appear (to me) as pure
> magic?  I don't understand it, yet I'm expected to produce XML from
> it?

I hope the details of the proposal made it clearer how this works.

Even if a processor doesn't understand the pragma, it will understand
the syntactic form of the pragma as defined in the ixml grammar for
ixml, and the required XML has the same relation to that syntactic
form as for any ixml grammar.

> Design questions: Could pragmas be 'associated with' (external to) a
> grammar as apposed to within it? How to 'point to' the modified
> grammar element?

Not in this proposal, no.

> If a pragma results in a non-wellformed XML output, is that a user
>  issue?

I think it's either a quality-of-implementation issue for the
processor that produces the non-wf output, or a
quality-of-specification issue for the document that defines the
pragma itself.

Nuffin to do wiv me, guv.

> ## The brackets-QName proposal

> Scope issue: "Serializing a nonterminal as an element or attribute
> whose name is taken not from the grammar (as in ixml as currently
> specified) but from the input data." Implies that pragmas scope
> extends beyond ixml to other data sources? Is this a required
> complexity? I'd vote against this.

Not sure I follow here.

The idea is that the pragma affects the way a processor serializes
the parse tree.  The scope of the pragma (as I understand the term)
is a clearly defined region in the grammar.  The effect of
understanding and implementing the pragma will be visible in the
output, without the pragma's scope extending outside the grammar.

> Fixed form: [? qname Variable form:

> "all pragmas have the same representation in XML grammars."  Is this
> a valid statement?

The use of 'same' is perhaps a little loose.  They will have different
pragma data and different pragma names and different pragma marks.
But they will all be elements named 'pragma'.

> "The xml form of pragmas" - is this of use to a user? First
> introduction, I'm unsure if / when it may be of use.

Since I work quite a lot with ixml grammars in XML form, I am keen to
have pragmas well defined in the XML form of the grammar.

> "Any pragma recognized can be written out in ixml notation. " A bit
> tautological? Surely it needs to be written out in ixml notation to
> be recognised?

I think that pragmas can be defined so that they can be recognized
within the XML form of the grammar.


> ## Worked examples

> "... and that namespace bindings should remain constant throughout
> the grammar " Now that would be helpful :-)

> "a pragma-aware processor " First mention - should be defined, also
> action on a non-aware processor finding a pragma

The term 'pragma-aware' may have been ill chosen.

If the proposal is adopted, all processors must be aware that pragmas
may occur in grammars and must be prepared to parse them.

In this bit, 'pragma-aware processor' was meant to denote a processor
which understands some pragmas and must be able to tell whether a
pragma it encounters in a grammar is a pragma it understands, or a
pragma it does not understand.

A processor that 'understands' no pragmas does not have that task:  it
can simply parse past all pragmas and ignore them when parsing input
against the grammar.

> "at least one thing must be specified in the spec for the
> bootstrapping process to work: either a magic prefix, analogous to
> the xmlns prefix of the XML Names recommendation" Seems a sensible
> way of processing, to (re)use xmlns? +1 from me.

You may be right.  My views are colored by the fact that I hated the
way the namespaces spec solves this problem and still hate it twenty
years later.

> "We can do this in ixml by expanding the grammar, splitting each
> nonterminal into two rules, one producing a visible serialization
> and one hiding the nonterminal on serialization." Is this desirable
> | needed? Perhaps nice if it can be automated + hidden from the
> user.

It's just an example, and not itself proposed for the spec.

But the serialization idiom described is one that John Lumley and I
have each hit upon independently, which seems to me to suggest that at
least some people find it desirable.


> ### Text injection

> "To express this grammar in ixml, we need either (1) to allow
> multiple rules for the same nonterminal, or (2) to allow pragmas
> before connectors like comma or semicolon, or (3) we need to allow
> string-to-typed-value functions in the style of XPath. " Another
> tweak of the ixml grammar? Could this be implemented without such a
> tweak?  What's the relative value added vs the saving in typing (or
> macro execution).

Again, this is just describing the problem facing someone who wants to
use pragmas to handle attribute grammars.  That person does not get to
tweak the ixml grammar (at least not in an interoperable way).  There
was some uncertainty for a while over whether we needed to do the
tweak to allow this kind of use case to work, but if memory serves I
was able to persuade myself that the attribute-grammar use case can be
solved without changing the grammar of ixml.


> ## Open issues

> Question: If (generally) the issue is that the full extent of XML
> cannot be achieved from ixml, then IMHO that's fine. Please don't
> let corner cases bug you. "Con: things are complicated enough as it
> is. " Quite agree. KISS?

> ## Decisions

> Third: Ask W3C (who?) and if agreed, use xmlns (well understood).

> Fourth: +1 to using "http://www.w3.org/2000/xmlns/" or even /2021
> heaven forfend.

> Summary: I don't pretend to comprehend some of the issues above. It
> appears to me akin to moving from rng to xsd. I do hope others see
> it as being of **user** benefit.


> regards Dave P

...

> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.

Received on Tuesday, 14 December 2021 14:27:48 UTC