Re: Requirements & pragma proposal

> 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

Received on Tuesday, 14 December 2021 14:51:05 UTC