W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: JFV and Common Structure specifications

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 23 Nov 2016 11:56:53 +1100
Message-ID: <CABkgnnXwOOmv3sJKrufs19ErUNA65iMm32aypRBH=z+F8mWGSQ@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
On 22 November 2016 at 20:51, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> But I see absolutely no advantages for us or anybody else, in trying
> to impose that policy on everybody else, by delivering CS as a less
> capable tool[1].
[...]
> [1] In my very extensive study of computing history, I have _never_
> found an instance where that strategy worked for anybody, and
> computing today is litered with examples of the opposite: C++ vs
> C, PHP vs Perl, AMD64 architecture vs Itanic, GPL/GCC vs CLANG,
> and so on.

JSON.  The principle you are looking for is "just barely good enough
to work".  And that applies to the web in spades if you want great
object lessons.

Let's not talk about policy and instead concentrate on cost-benefit.
Mark has summarized the costs quite well, I think.  I would go further
and point out that a recursive syntax with quoting cannot have
elements that are skipped by a parser, which I find results in simply
externalizing those costs.

The onus on you is to justify these costs in terms of tangible
benefits.  Concrete use cases might help.

(BTW, I like your onion layers concept, though I'm sure that Roy would
chime in and point out that this is a feature of Waka.)
Received on Wednesday, 23 November 2016 00:57:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 November 2016 00:57:28 UTC