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

[Tatu Saloranta <[e-mail]>]

On Wed, Feb 19, 2014 at 10:43 AM, Phillip Hallam-Baker <[e-mail]>wrote:

>
>
> 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.
>
>

I agree completely with above.

-+ Tatu +-