[Json] Namespacing and avoiding pathologies

Phillip Hallam-Baker <hallam@gmail.com> Thu, 20 February 2014 19:41 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 34BE21A0176 for <json@ietfa.amsl.com>; Thu, 20 Feb 2014 11:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DfT-zg2RSjDN for <json@ietfa.amsl.com>; Thu, 20 Feb 2014 11:41:53 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4E1A0235 for <json@ietf.org>; Thu, 20 Feb 2014 11:41:53 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id e16so1639484lan.26 for <json@ietf.org>; Thu, 20 Feb 2014 11:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=knB/+lBNLdDWFSxDmyrTxrcuDCqvI3koggIzR8z1Q/I=; b=kv5biq1eFIGjgXzUBwJiJXnXECbrNStLFJ35ETZ9yGK3E/QCyFbfyd0czXVshnbc+h tv0YX6O/DwPLj9WJtKcTWCs3G5EXlIWomi4lRIb2pksqKj65Pe0o72fba0hsiLICcgxN 8JMCBc1knsLgjr2XYLDHyKDEY3sIOeUyugol6Brch8ksVWUuKN4HDzq2ZNLLiyrKtQNP L6VDduGe6Nz1lsoABVc+r3zxd/YQm3Tge6yZHwS8NlBCoZlKpznxya3xHUfA5U+F8Qiw hNQ3O4xxM44jrGvi+CLfd3itQoX+zDyPqHh6cWsqdDg26jjPKFOOC/uhmm6rkLLLDoqm aKWA==
MIME-Version: 1.0
X-Received: by with SMTP id qt9mr2099094lbb.34.1392925309172; Thu, 20 Feb 2014 11:41:49 -0800 (PST)
Received: by with HTTP; Thu, 20 Feb 2014 11:41:49 -0800 (PST)
Date: Thu, 20 Feb 2014 14:41:49 -0500
Message-ID: <CAMm+LwjWjOTh=15zSFjHYhqJ=1zwGah-k++nypjFHge3VFiq0w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary="089e0122971040807a04f2dbb263"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/J_rt_GKpA2rp1yrErnV8d8fWMEg
Subject: [Json] Namespacing and avoiding pathologies
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2014 19:41:56 -0000

How the system currently works for ASN.1 OIDs and used to work for RFC-822
headers (remember X-headers?)

1) Group of independent developers create a spec
2) Spec gets used in practice
3) They decide to take it into the IETF
4) Someone suggests putting the OIDs under the IETF arc (e.g. under PKIX)
5) Implementations now need to track two identifiers for everything

Trying to short circuit the process is worse. I have been waiting on some
PKIX OIDs for 18 months now. And every time I ask the answer is 'yes'.

So here is what I propose:

1) There is no JSON or IETF root to the arc. Each project builds its own
arc with itself as the root

2) The root of a JSON namespace is registered as a .well-known service
regardless of whether it is a Web Service with a HTTP binding or not. All
that matters is that there are no collisions.

So here is how it would work for OmniConnect

* Well Known service code point is JsConnect (say)
* Root of the name space is JsConnect
* A transaction is Open with messages OpenRequest and OpenResponse

If there is another protocol making use of JsConnect, they might have their
own Open transaction that builds off the JsConnect protocol

Protocol Foo NewNamespace
    Import JsConnect

    Transaction Open JsConnect.OpenRequest  OpenResponse

    Structure OpenRequest
        Inherits JsConnect.OpenRequest
        String ExtraData

Behind the scenes an implementation is likely to want to take the
namespaces defined in the protocol and shuffle them down a level. So I
actually declare JsConnect as being in the Goedel.JsConnect namespace. But
this is something that is an implementation dependent issue that can and
should be handled separately. I have always found the way XML Schema works
by trying to pull in documents via URIs to be bogus and the hardcoded files
to be worse.

It should be possible to have a command line to kick the translator that
reads something like:

protogen project.protogen -settings mysettings.protogen -cs -c -h

Which means 'read in the source file from project.protogen, apply the
namespace mappings described in mysettings.protogen and write the code for
C#, C and C header file into project.cs, project.c and project.h'

mysettings.protogen might contain a declaration like

    Root   Comodo.Open

    Language C
        Prefix JSX_
        String CharZ

    Language C#

What this says is that in C# and other languages that support namespaces,
prefix the namspaces with Comodo.Open so generate Comodo.Open.NewNamespace
rather than just Namespace. This also allows someone to support two
different versions of the same spec using code in different namespaces.

The 'Stubs' directive says to write out some dummy code stubs for testing.
And in C we are spcifying a prefix to be added to the front of every
identifier and that we want to use null terminated strings. We might also
have a directive to choose the memory allocation model.

I don't do Java but it is obviously an important language people would want
supported. If someone could take one of my C# output files and convert it
to Java, I can reverse engineer the changes back into the tool. It is
almost certainly close as it is. The main challenge with Java is that every
class has to be its own file and partial classes are not supported. Which
is rather a horrorshow for code synthesis tools. C# makes it easy to
separate the machine generated and synthesized code, Java was written by
people who had been burned by C++.

Website: http://hallambaker.com/