Subject: [Json] Modularity and composition

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Mar 2014 10:06:33 -0400

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/

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Mar 2014 08:18:09 -0700

On Mar 15, 2014, at 7:06 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> I strongly support removing the namespace parameter for I-JSON.

Please note that the consensus call was for the -01 draft, which has no namespace. If the WG adopts the work, it would start with the -01 draft, and the call indicated.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Mar 2014 13:28:30 -0400

On Sat, Mar 15, 2014 at 11:18 AM, Paul Hoffman <[email-masked]>wrote:

> Please note that the consensus call was for the -01 draft, which has no
> namespace. If the WG adopts the work, it would start with the -01 draft,
> and the call indicated.
>

And I want it to stay that way.

At the moment I-JSON is a strict subset of JSON which is useful. If people
add in extensions then the point is lost because people who want the subset
may not want the extensions.

We can come to agreement on what I-JSON should look like pretty easily. But
coming to agreement on how to make JSON modular is a much bigger piece of
work and that needs to be considered separately.