Requirements & pragma proposal

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.

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 12:31:08 UTC