[Json] Modularity and composition

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

I strongly support removing the namespace parameter for I-JSON. I
understand what is being attempted there but it does not work in XML so I
see no reason to repeat it. Here is what I think works instead. I don't
think this should become part of the I-JSON draft but it would be useful to
describe it as an example of one approach to JSON modularity.


The key feature that JSON has which XML does not is that a JSON tag may be
any valid UNICODE string. That means that we can put a URI in it.

Now what makes more sense to you:

{ "tag1" : "you don't know what this is about yet",
   "jsonns" : "urn:iana:protocols:foo:v1"
  "tag2" : "more tags at the same lexical level as the namespace" }

or

{  "urn:iana:protocols:foo:v1" {
 "tag1" : "The enclosing tag shows what this is all about",
  "tag2" : "More tags within the defined space" } }

What I really like about this approach is that it is clear that what is
being included is a separate data object that should be handed off to a
separate handler.


One of the more awesome features of the .NET platform is that it allows
service applets to register code to handle parts of the HTTP URL namespace.
So you can register a handler for "http://example.com:8000/.well-known/foo".

But the URL space is an administrator space. Not a protocol space. The
command type should be specified in the protocol messages not the transport
binding. Having the protocol commands passed in HTTP headers makes no more
sense than putting them in TLS extensions.


This lexical approach would make it possible to do similar tricks within a
handler for JSON based Web services. Let us imagine that we decide to
package up our request and response data as follows:

{ "urn:iana:protocols:foo:v1:GET-Request": { ... ...}}

or maybe the URI stem is implicit:

{ "GET-Request": { ... ...}}

Note that all the information relevant to the protocol is now in one place.


The part where the wheels came off the tomato for XML namespace was when we
tried XML Digital Signature. That led to canonicalization which let to
bizarre transformational approaches. Yuk!

The approach I suggest here works really well with signed or encrypted data
objects. The only catch is that you have to understand that Digital
Signatures sign a list of octets and not an object. So this approach is
doomed to fail:

{ "Signed-Data":  { "tag": "Never gonna work reliably"}}

To get the scheme to work we have to Base64 the signed data so that the
sender.


[At ths pont the  and  ey on my MacBoo have broen so the rest mght be
dffcult to read and  wll stop.]



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