Re: draft agenda for ixml community group call, Tuesday 10 May 2022

> ****************************************************************
> Topic: Previous Actions
> ****************************************************************
>
> ACTION 20220426-01: Norm to propose spec and grammar changes for a
>        version declaration.

Completed, waiting to be merged:
https://github.com/invisibleXML/ixml/pull/78

> ACTION 20220426-03 Norm to update the spec with error codes.

Completed, waiting to be merged:
https://github.com/invisibleXML/ixml/pull/77

> ................................................................
> ** Open issues 
> ................................................................
>
> Topic: issue #66 Namespaces proposal

There seem to be three options. In the interest of time, we should be
prepared to pick one today, I think.

1. The simple namespaces proposal adds namespace declarations to the
   grammar explicitly and adjusts a few productions to support qualified
   names in nonterminals.

2. Another proposal has been made that simply adds “:” to the
   namefollower production and leaves construction of namespace
   well-formed markup to the user.

3. If there’s no consensus to change the specification, we retain the
   status quo: there are no namepaces in ixml and no qualified names.
   But given that every member of the CG has expressed support for one
   or the other of the namespace proposals, this would seem an odd place
   to end up.

Several technical issues have been raised against the “just allow
colons” proposal. These have been analysed and described by members of
the CG and appear, at least to me, to be insurmountable:

  https://github.com/invisibleXML/ixml/issues/66#issuecomment-1102693242
  https://lists.w3.org/Archives/Public/public-ixml/2022May/0004.html
  https://lists.w3.org/Archives/Public/public-ixml/2022May/0011.html

Although we have not reached consensus on the simple namespaces
proposal, I’m not aware of any technical issues that have been raised
against it. I’ve demonstrated that it requires only a few small changes
to the grammar and the prose of the specification:
https://github.com/invisibleXML/ixml/pull/79

The simple namespaces proposal encapsulates namespaces as global
declarations applying to the entire grammar. This eliminates almost all
of the complexity associated with namespaces that arise in XML documents
“in the wild.”

When I first joined the CG, it was not obvious to me that namespace
support was necessary. But I’ve been persuaded that ixml without
namespace support will be an inconvenience for some users and pressure
will be on implementors to do something about that inconvenience.

If adding support was _either_ a burdon on grammar authors who didn’t
wish to use namespaces _or_ a large and complex change to ixml, I think
we could have a constructive debate about whether the value of the
feature was really worth the cost.

But it isn’t. Absolutely no existing grammar will break if we add
namespace support. No user will ever have to think about namespaces if
they don’t want to. Adding it to the specification requires adjusting a
few productions and adding roughly four short paragraphs of prose, a
tiny change even within the context of a small specification.

If we don’t do this, implementors will add mechanisms to support
namespaces that may or may not be reflected in the grammar text. If they
are reflected in the text, they’ll be non-interoperable. Users will
quickly find that they need specific implementations or entirely
different configurations for different implementations. Hardly the
hallmark of a successful standard.

If we fail to achieve consensus, I don’t think it will be possible to
argue that we were faced with two equally sound technical proposals and
could not decide which one to use, so we didn’t choose either. I think
we will be forced to say that despite the fact that our explicit goal
was to produce “a method for treating non-XML documents as if they were
XML, enabling authors to write documents and data in a format they
prefer while providing XML for processes that are more effective with
XML content”, we decided that supporting a significant feature of every
modern XML processing system wasn’t necessary or useful enough to
justify four paragraphs of prose.

I think doing so weakens the position of ixml far more than the small
additional complexity of supporting namespaces, even if some people
don’t like them.

If we add support for namespaces, to the user who says “I hate
namespaces”, we can say “then don’t use them.”

If we don’t add support for namespaces, to the user who says “I need
them”, we can say…use your implementation’s vendor-specific,
non-interoperable extensions, or add a new XSLT or XProc workflow to
your system, or use sed, I guess.

Only one of these converastions will make me uncomfortable and force me
to admit that, yes, I think the CG did let you down.

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica