Re: [Json] Nudging the English-language vs. formalisms discussion forward

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Feb 19, 2014 at 11:05 AM, Tim Bray <[e-mail]> wrote:

> I feel that successful Internet interoperation is achieved at the level of
> syntax; clear specification of which bytes should be sent and which
> returned.  Many times over the years I've heard assertions that if you get
> the data model right, then the syntax is ephemeral: JSON or XML or ASN.1,
> who cares? I've never found that notion remotely plausible, as there always
> impedence mismatches.  You end up having to fight over another syntax to
> describe the model before you can fight about the syntax you're going to
> send over the wire.
>

The point is to focus the discussion on the data going over the wire rather
than the syntax.


When the discussion is about syntax, that is usually a specification smell.
Take HTTP's weak e-tags

ETag: W/"who/ordered/this"

Now syntax is the very least of the issues that ETags raise. But the resort
to this particular syntax should have at least been a hint of the problems
to come.

Another peculiarity of the HTTP spec, there are two encodings for dates
that parsers must support. Both contain completely useless information (why
does a machine need to know the day of the week anyway). Both are
needlessly verbose but we are talking about compressing headers rather than
not sending irrelevant data. If people had not got into the weeds on syntax
we might have come up with a better caching model.


I don't see the value in having multiple encodings for a Web Service. But I
would much rather do that than end up with two separate specifications
because one group wanted ASN.1 and the other XML or some people want JSON
and others must have XML.

XML Web services have a whole ecology that some people are very heavily
bought into. They really can't use a specification that doesn't play nice
with that system.

JSON is the future for new work. But just as the PKIX people had a point
when they asked for an ASN.1 version of KEYPROV, there are going to be
people whose existing infrastructure is XML who want to make use of work
being done by a WG producing a JSON spec.


The point is that the function of this group and any other platform level
group is to support the work of the IETF WGs and the other groups that want
to build on top. If we can provide them with a mechanism that allows them
to provide a smooth transition path to the common encoding syntax, that
helps them meet their goals.


-- 
Website: http://hallambaker.com/