Re: When writing standards...

   - Fewer formats is better# <http://this.how/standards/#1497798798000>
   - If you can replace two formats with one, without breakage or loss of
      interop, then I say go for it.#
      <http://this.how/standards/#1497798794000>
      - Removing complexity from the world is always good.#
      <http://this.how/standards/#1497798814000>
      - Think of this like code factoring, but on a larger scale.#
      <http://this.how/standards/#1497798801000>
      - This is 1/2 of Postel's robustness principle
      <https://en.wikipedia.org/wiki/Robustness_principle> -- be
      conservative in what you send.#
      <http://this.how/standards/#1497798816000>

Who is this semi-divine "you" who gets to impose uniformity?

"Removing complexity"  is just guff: complexity is not an absolute thing
that is unrelated to technical debt, use cases, and so on: the alphabet
would be less complex without the letter C, but removing it would be
enormously impactful for no benefit. Elegance is good for new things, but
standards are frequently not new things, they are messy snapshots of
technology in evolution.

There is another law that is co-equal and in tension with Postel's Law: "A
Spoonful of Sugar helps the Medicine go down". This Law crops up in Larry
Wall's maxim roughly that simple things should be simple to do. But what is
"simple" is usually what is "frequent", and what is frequent depends on the
use-case, which brings us back to the point that spurning technologies by
fiat becomes an exercise in denying the use-cases of others. A standard is
an agreement on some technical description developed formally or informally
in the light of some explicit and reasonable quality methology, hopefully
with some indication of its motivating use case and sweet spot.

   -
      -
      - Write specs in plain English#
   <http://this.how/standards/#1497798836000>
   - I write for people who have brains, like to think, are educated, care
      about interop. I understand that people reading specs are not computers.
      # <http://this.how/standards/#1497798847000>

Plain English is not good enough, because important permissive/volitional
words like "must", "should", "can", "may", "might", "will" and their
negatives are ambiguous and even region-dependent. Those, at least, need to
be explicit and controlled. Especially where there is legal intent.
Furthermore, more non-native speakers read English than native speakers:
the pronoun "it", in particular, is a tarball of confusion. But "plain
English" without "it" is just not plain.

So I appreciate the intent (cough XSD splutter), but I think the key is
that where simple, formal/executable/lintable ways to express things exist,
these should be used: BNF, regular expressions, Unicode character classes,
XPath, DTDs, UML, etc and so on, with the helpful English being
non-normative peritext.

Regards
Rick



On Wed, 5 Apr. 2023, 01:20 Dave Pawson, <[email protected]> wrote:

> @dw
> http://this.how/standards/
>
> Sounds very sensible.
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: [email protected]
> subscribe: [email protected]
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>