pragmas outside the ixml spec - an invitation

The CG's decision to abandon our work on pragmas leaves those of us
working on a Balisage paper presenting the pragmas proposal with a
slight dilemma.  Either

  (a) the paper becomes a post mortem report describing was proposed but
      not adopted by the group, explaining the fine points of a design
      in which the fine points no longer matter,

or else

  (b) the paper becomes a description of an add-on to ixml: not part of
      standard ixml, so not guaranteed to be supported by all conforming
      ixml processors, but an additional facility which may or may not
      be supported by processors, just as the functions in the EXSLT
      namespace are not part of the XSLT spec but are supported by some
      XSLT 1.0 (and 2.0 and 3.0) processors.

This is to place on record that I think (b) is the preferable option,
and to invite any members of the CG who agree that (b) is preferable to
collaborate with me to refine the pragmas proposal as an extension
layered over standard ixml.

To ensure that pragmas are not rejected by standard processors, it will
be necessary to change the pragma delimiters to include "{" + something
and something + "}"; I regard that as unfortunate, but since I don't
particularly want to fork the ixml effort it's a price I am willing to
pay.

In the proposal as I expect to describe it, pragmas will thus be
structured comments, just as in other languages where structured
comments are an unfortunate and ugly hack made necessary by the failure
of the initial specification of the language to provide a distinct
syntax for pragmas.  The one thing we can do differently in the ixml
ecosystem is for those who see the need for pragmas to agree at the
outset on common implementation-independent rules for handling pragmas
in the form of structured comments.  The CG has not been able to achieve
consesus on such rules, so I propose that we use the Balisage paper on
the pragmas proposal to sketch out a proposal.

If a significant percentage of the initial crop of ixml processors
implement pragmas as defined in the Balisage paper, then we may be able
to set expectations among ixml users that implementations should not
just roll their own syntax for structured comments, but should use an
implementation-neutral syntax designed to avoid collisions.  That won't
be binding on future implementors, but it may encourage them to do the
right thing.

CG members interested in working with Tom and me to reformulate the
pragmas proposal as a separate spec (an ixml profile, in effect) layered
over ixml are invited to let me know by email.

Michael

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Wednesday, 6 April 2022 22:45:37 UTC