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

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

On Wed, Feb 19, 2014 at 12:25 PM, John Cowan <[e-mail]> wrote:

> Tim Bray scripsit:
>
> > > The point is to focus the discussion on the data going over the wire
> > > rather than the syntax.
> >
> > Here is where we disagree absolutely. The point is to specify the syntax
> > clearly and unambiguously, and the semantics of its payload.  Trying to
> > come at it from the other direction (specifying data structures and then
> > extracting syntax) leads to huge mistakes like CORBA and WS-*.
>

They are only mistakes because they are huge. Microsoft and IBM wanted to
build a consulting business which meant that they liked a specification
that was overly complex.

The whole ProtoGen system is less than about 5,000 lines of code and it has
equivalent functionality to the WS-* stack.

XML isn't the farce that SGML was and JSON is even simpler than XML without
loss of power (though it does not make a very good document markup).

C# and Java are not the screwups that C++ was either. And C is not ADA.

The fact that the B-crew has botched a job in the past does not mean the
approach is wrong. The collapse of ADA did not prove that high level
languages were a bad idea. Though there were folk on USENet making that
argument at the time. My college tutor was known for having walked out of
the ADA design meetings but he still worked on many other programming
languages afterwards.



> I agree absolutely with Tim, if it wasn't clear before.  Semantics is vague
> and fuzzy (my semantics of your JSON may consist solely in counting the
> number of fields in the top-level object, for example).  Syntax is not.
> Agreement on syntax promotes interoperation; agreement on semantics
> takes forever, pushing syntax to the rear, thus tending to create bad
> syntax.
>

JSON has no semantics, All the JSON syntax has is a mapping to an implicit
data model.

Semantics can be defined very precisely and most modern computer science
courses teach methods of doing that Z, VDM and the rest are all very
precise ways of specifying the behavior of a protocol with as high a degree
of precision as LR(0) parsers allow for syntax.


What I have found is that making use of syntax to encode semantics is
always a mistake. For example we might have a specification that says that
a Date field can either be an RFC3337 DateTime or an integer giving the
offset in seconds from the current time. That is certainly possible but we
now require the parser to be able to recognize the format of the data and
select the representation appropriately. Maybe 95% of people will do that
right but at least 5% will do it wrong and if one of those implementations
becomes popular we end up with a specification that now has three different
cases to code, the two in the spec and the real life situation that isn't
documented.

Using different tags for "DateTime" (=String) and "DeltaTime" (=Integer)
avoids that whole business.


When people reach for Regular Expressions they are almost always doing
something that is better done without.


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