Re: Requirements & pragma proposal

I would add for completeness:

5. Pragmas may occur as an annotation to a rule, terminal, or non terminal, where they apply to the thing they're annotating; or within a rule, where they again apply to the rule; or as an alternative to a rule, where they apply to the grammar as a whole (i.e. the `ixml` element in the xml representation).

_________________
Tomos Hillman
eXpertML Ltd
+44 7793 242058
On 14 Dec 2021, 14:51 +0000, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>, wrote:
>
>
> > On 14,Dec2021, at 5:13 AM, Norm Tovey-Walsh <norm@saxonica.com> wrote:
> >
> > Having arrived to the group late, I didn’t have any expectations for the
> > pragmas proposal. It’s fairly ambitious, but it seems well designed.
> >
> > Intuitively, it feels like something I’d prefer to have in V1 than see
> > added later. But it also feels like it’s substantial and would take a
> > fair bit of time to shake out fully. And I think the proposal is longer
> > than the current ixml spec, so there’s a sense in which it feels like
> > it’s adding quite a bit of complexity.
>
> My apologies. One reason the proposal is so long is that
> I needed to persuade myself that it would work to solve
> the kinds of things people were suggesting it might solve.
>
> But proposal F amounts to this:
>
> 1 Some mechanism for declaring namespaces is needed, so that
> pragmas can have QNames; the document defines two ways
> to do this and proposal F is not fussed about which one is chosen.
>
> 2 Pragmas have the syntax given: ‘[‘, pmark?, QName, s, pragma-data, ‘]’.
>
> 3 When the ixml grammar is translated into an XML grammar,
> pragmas have the XML form implied by the syntax of pragmas
> (and this point thus does not need to be mentioned in the spec).
>
> 4 The schema for the XML form should also allow pragmas
> to contain additional elements beyond pragma-data.
>
> Everything else in the pragmas.md document amounts to a
> long and pedantic argument that these four points are
> enough, with worked examples showing that the mechanism
> described suffices for the use cases.
>
> It is not spec prose and not intended to be spec prose. It
> should turn into a few paragraphs of spec prose.
>
>
> >
> > That said, the requirements sketched out for V2 feel like they’d be
> > better addressed with something like the pragmas proposal than through
> > ad hoc syntax extensions. I’m not, for example, especially keen on the
> > “nonterminal^serializedname” syntax.
> >
> > One of the benefits of XML is that we have a extensive set of tools
> > designed to query, transform, and otherwise manipulate it. They work
> > well, they’re well understood, and widely available.
> >
> > I think one could take the philosophical position that *all* ixml needs
> > to do is get non-XML data into XML. Anything you want to do after that:
> > add namespaces, rename elements, insert text, etc. is an XML problem and
> > ixml doesn’t need to solve it.
> >
> > You could imagine an ixml step being a first stage of a *cough*
> > pipeline, for example.
> >
> > > * Context sensitivity
> >
> > With respect to this requirement, there must be history about it that
> > I’m unaware of. It surprises me here and it surprised me a little bit in
> > the pragmas proposal. It’s in opposition to the V1 requirement that
> > users shouldn’t have to know the finer points of parser theory. Perhaps
> > it’s a consequence of my implementation strategy, but it doesn’t feel
> > like something I’d be anticipating supporting unless, perhaps, it
> > applied to the whole grammar. But I’m still a n00b about how this is
> > going to work and be used, so I’m prepared to discover differently.
> >
> > Be seeing you,
> > norm
> >
> > --
> > Norm Tovey-Walsh
> > Saxonica
>
>