[Json] Namespacing and avoiding pathologies

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

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

Mapping
    Root   Comodo.Open

    Language C
        Prefix JSX_
        String CharZ
        Stubs

    Language C#
        Stubs

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/