Subject: [apps-discuss] draft-saintandre-json-namespaces-00 comments

From: Dominik Tomaszuk <[email-masked]>
Date: Tue, 08 Nov 2011 13:42:55 +0100

Hi Peter,

Clark Notation can sometimes be too heavy, especially when namespaces 
are placed in many keys. I propose to give possibility to declare 
namespace. For instance:
{
   "$namespaces": {
     "foo": "http://example.com/foo"
   },
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "{$foo}bar":"baz"
}
This capability allows JSON documents to be lightweight.

Best regards,
Dominik Tomaszuk

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Nov 2011 09:05:08 -0800

On Nov 8, 2011, at 4:42 AM, Dominik Tomaszuk wrote:

> Clark Notation can sometimes be too heavy, especially when namespaces are placed in many keys.

+1

> I propose to give possibility to declare namespace.

-1. Actually, -10. While somewhat useful for XML, namespaces have also proven to cause many headaches for corner cases.

Please strongly consider using a much simpler naming scheme, such as "names with periods in them".

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Nov 2011 18:05:06 +0100

On 2011-11-08 13:42, Dominik Tomaszuk wrote:
 > ...

This copies a design pattern that many people hate in XML namespaces 
(*not* including myself...).

Also, if compactness is an issue, the obvious answer is to gzip the payload.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2011 11:10:44 -0600

+1 to Paul's -10.

My take on it:

http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json

Let's keep this simple and avoid repeating the mistakes of XML, OK?

On 08/11/2011, at 11:05 AM, Paul Hoffman wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Nov 2011 19:12:50 +0100

> Let's keep this simple and avoid repeating the mistakes of XML, OK?

Well, there are two different issues:

1) Using URIs for disambiguation, and

2) Using a prefix-URI mapping to make things more compact.

The reasons for 2) would be readability and compactness, but would make 
processing the content much more complex. I don't believe it's needed here.

Re 1) -- well, if you have URI-based identifiers to start with, there's 
little choice. You could declare the problem to be an SOP, in which case 
you shouldn't even look at the draft. Or one could introduce yet another 
indirection mechanism (-> 2).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2011 13:10:53 -0600

I don't think URIs should be used for this.

On 08/11/2011, at 12:12 PM, Julian Reschke wrote:

> The reasons for 2) would be readability and compactness, but would make processing the content much more complex. I don't believe it's needed here.
> 
> Re 1) -- well, if you have URI-based identifiers to start with, there's little choice. You could declare the problem to be an SOP, in which case you shouldn't even look at the draft. Or one could introduce yet another indirection mechanism (-> 2).
> 
> Best regards, Julian

--
Mark Nottingham
http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Nov 2011 20:18:40 +0100

> I don't think URIs should be used for this.

Well, one use case that the proposal is addressing is the transport of 
data from frameworks that *already* use URIs; such a WebDAV properties 
or JCR identifiers. In these cases you really have only the choice of 
using the identifiers you have, or establishing a completely new 
identifier system.

And yes, it would be helpful if the draft was just saying that and not 
make the impression that it was solving the generic problem for JSON.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2011 13:20:45 -0600

On 08/11/2011, at 1:18 PM, Julian Reschke wrote:

> Well, one use case that the proposal is addressing is the transport of data from frameworks that *already* use URIs; such a WebDAV properties or JCR identifiers. In these cases you really have only the choice of using the identifiers you have, or establishing a completely new identifier system.
> 
> And yes, it would be helpful if the draft was just saying that and not make the impression that it was solving the generic problem for JSON.

Ah. I see that as almost an application-specific issue, nothing that should be standardised. Doing that would be leaving sharp tools around small children.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Nov 2011 20:23:34 +0100

> Ah. I see that as almost an application-specific issue, nothing that should be standardised. Doing that would be leaving sharp tools around small children.

I think it's worthwhile to have a spec that says:

"If you're identifiers are XML names, then this how to use them in JSON. 
But if you don't have identifiers like these, don't *start* using them 
if you want to use JSON."

Which of course leaves the question open what to do instead :-) (and 
yes, I saw your proposal)

Best regards, Julian

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 08 Nov 2011 11:31:51 -0800

My 2¢: Leave the field wide-open. Let implementers pick the namespace
that gives them the best comfort of avoiding collisions. As far as I can
tell, the best to pick from would be: reverse-domain-name-prefixed
dot-delimited value, URI w. scheme, and even OID in some cases. Allowing
all of these namespace conventions seems to avoid all the collisions
that I can currently imagine.

Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Nov 2011 05:57:13 +0800

And another +1 to the -10.

To make the reason clear, the problem this causes is that names are no longer able to be treated opaquely.  Having "{$foo}x" with more than one potential semantic in the same context is a crazy sort of problem that only an unnecessary optimization can produce.

I'm generally with Mark, and Paul.  The lessons learned from "X-" and XML indicate that a private playpen is nice.  Proscribing the shape of that playpen seems unnecessary, at least for now.  

On the one hand, you could attempt to establish a convention for the shape of the playpen.  This draft does that with {} and URIs.  There's certainly merit in convention, but the proposal is heavyweight.

On the other, all you need is a mechanism to avoid collisions in a given host format.  Given the identifier's inherent opacity, extensions can take any form (c.f. Paul's comment) and the goal is still achieved.  You can use a registry and bear the management overhead; use dotted names, uris or something similar; you can just use real names and risk collisions; or you can combine the approaches.

For instance, you could say: "official" extensions wont use '.', come see us if you want one; otherwise, try to play nice.  For instance, I haven't seen too many problems with namespace collisions in Java class names.

--Martin

On 2011-11-09 at 04:10:44, Mark Nottingham wrote:
> > -1. Actually, -10. While somewhat useful for XML, namespaces have
> also proven to cause many headaches for corner cases.
> >

---

From: Mark Baker <[email-masked]>
Date: Tue, 8 Nov 2011 19:51:08 -0500

On Tue, Nov 8, 2011 at 2:23 PM, Julian Reschke <[email-masked]> wrote:
> "If you're identifiers are XML names, then this how to use them in JSON. But
> if you don't have identifiers like these, don't *start* using them if you
> want to use JSON."

Completely agreed, though XML names aren't the only ones grounded in
URI space (e.g. RDF).

> Which of course leaves the question open what to do instead :-) (and yes, I
> saw your proposal)

After working with it for a couple of weeks, I agree completely with
Manu (in the comments of Mark's blog post); JSON-LD is a terrific fit.
It uses the same basic approach suggested in the message which started
this thread, and has other features which make it easy to bolt-on to
existing JSON based formats, in many cases without breaking existing
recipients.

http://json-ld.org

Mark.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Nov 2011 18:19:17 -0800

> http://json-ld.org

I would prefer that the output of this work was much, much simpler than this.

--Paul Hoffman

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Nov 2011 11:03:32 +0800

> I would prefer that the output of this work was much, much simpler 

+1.

@context is essentially the same as XML namespace prefixes, with the same basic problem: two labels can have different semantics, determined by another "special" label.

---

From: Mark Baker <[email-masked]>
Date: Wed, 9 Nov 2011 10:19:32 -0500

> I would prefer that the output of this work was much, much simpler than this.

JSON-LD lets the people who need URI-grounded names have them, but at
the same time presents enough of a barrier to discourage those who
don't need them from using them.  The last thing JSON needs is the
simple equivalent of xmlns.

Mark.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Nov 2011 08:20:42 -0800

On Nov 9, 2011, at 7:19 AM, Mark Baker wrote:

> don't need them from using them.

Great! Then let those people adopt it. I would prefer that the output of *this work* in the IETF be much, much simpler than JSON-LD.

>  The last thing JSON needs is the

JSON doesn't need anything: JSON-using communities do. They should have good, simple, standardized tools.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Nov 2011 09:31:20 -0700

> make the impression that it was solving the generic problem for JSON.

There's always an opportunity for publishing -01. ;-)

I agree that a range of approaches might be appropriate among JSON-using 
communities -- pretty much the same range of approaches mentioned in the 
x- draft:

        implementation-specific and
        private-use parameters could at least incorporate the
        organization's name (e.g., "ExampleInc-foo" or, consistent with
        [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g.,
        "com.example.foo" or a Uniform Resource Identifier [RFC3986] such
        as "http://example.com/foo").

I'll work with my co-authors to submit -01 next week or soon thereafter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tim Bray <[email-masked]>
Date: Wed, 9 Nov 2011 08:31:42 -0800

FWIW, I'd like to go on the record with my opinion that this work is
misguided.  This is a solution looking for a problem.   Clearly, a
robust JSON-based protocol SHOULD have a MustIgnore policy for things
it don't understand. And if I were putting things into a JSON message
that was to be tied to my software, it'd look like

{
    "size" : 23,
    "name" : "foo"
    "com.textuality.inferential-interfluidity" : 42
}

I think there are better ways to spend our time than on designing
something that really is not needed.

 -T

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Nov 2011 11:22:51 -0600

+1

--
Mark Nottingham
http://www.mnot.net/

---

From: Mark Baker <[email-masked]>
Date: Wed, 9 Nov 2011 12:43:06 -0500

> Great! Then let those people adopt it. I would prefer that the output of *this work* in the IETF be much, much simpler than JSON-LD.

Perhaps I wasn't clear; I'd prefer that there be no more work done, in
the IETF or anywhere.  I think JSON-LD is good enough for anybody
needing URI-grounded names.

Mark.

---

From: Dominik Tomaszuk <[email-masked]>
Date: Wed, 09 Nov 2011 21:21:42 +0100

> -1. Actually, -10. While somewhat useful for XML, namespaces have also proven to cause many headaches for corner cases.
I do not propose to reject Clark Notation and add declarative XML-like 
namespaces. My proposal was optional. If like long Clark Notation URLs' 
you can use it (advantage: easy processing). If you want short and 
non-repeated namespace you can declare it and use only reference 
(advantage: smaller and easier to read file).

All proposals for shortening are similar to my. You can use something 
like QNames, CURIE, or JSON-LD terms, but it is almost the same - all of 
them should be declared first.

Best regards,
Dominik Tomaszuk

---

From: Dominik Tomaszuk <[email-masked]>
Date: Thu, 10 Nov 2011 10:39:45 +0100

Best regards,
Dominik Tomaszuk

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Nov 2011 10:50:45 +0100

On 2011-11-10 10:39, Dominik Tomaszuk wrote:
>> -1. Actually, -10. While somewhat useful for XML, namespaces have also
>> proven to cause many headaches for corner cases.

The added complexity is there, even if it's optional.

> (advantage: smaller and easier to read file).

Again, why would you want it? In XML, manual editing and recomposing was 
a use case; do you think the same it true for JSON?

Best regards, Julian

---

From: Dominik Tomaszuk <[email-masked]>
Date: Thu, 10 Nov 2011 11:08:48 +0100

> The added complexity is there, even if it's optional.
Agree, if you use it.

> a use case; do you think the same it true for JSON?
Yes, I do.

Best regards,
Dominik Tomaszuk

---

From: Dominik Tomaszuk <[email-masked]>
Date: Thu, 10 Nov 2011 11:46:30 +0100

On 10.11.2011 11:12, Julian Reschke wrote:
> So you're editing JSON payloads in a text editor?

Sometimes, but more often I edit MongoDB console.

Best regards,
Dominik Tomaszuk