Comments on: Adding Namespaces to JSON

By: Lee

Lee — Tue, 29 Mar 2011 06:24:29 +0000

Yes, being a programmer I completely disagree with you because I can already envision the code which is not all that big and can simply make use of the user function that current parsers already permit.
All the developer would have to do is check for the namespace node on the root in his own function which actually makes it easy for him/her to bypass wrong json and use a variable string to capture the name correctly, for instance:
t = ”;
if (root.namespace) { t = ‘ns_’; }
switch (name) {
case ‘plist’: l = obj[name];
for (i = 0…) { o = l[i][t + 'person'];… }
} // not hard and the middle function would simply be a modified version of the one further above.

By: Administrator

Administrator — Tue, 29 Mar 2011 03:08:33 +0000

All of which makes the JSON 10x more painful to deal with. How much easier it would be to just parse the JSON in as is, no translations and be done with it. Because names are DNS they are all unique and even human readable. With the containment proposal every path gets long and longer. But oh well, I think we can just agree to disagree.

By: Lee

Lee — Sun, 27 Mar 2011 18:56:02 +0000

Namespace ids can be used, if the object isn’t created then the namespace id will not be loaded into the parent object. Even if the programmer doesn’t test for the existence v.NAME the script will fail to continue because it has no data to work with. e.g:
ns : { g : { id : ‘person’, name : ‘org.foo’, src : ‘URL’ } }, data : { ns_g : { fname : ‘Lee’ } } // ns_g would tell the parser to create a object called person in data using ns_g data as the default properties and their corresponding values
// then…
if (json.person) {
// continue
} else {
// root is not data
} // for arrays the parser would wrap an object around person before adding it to the array

By: Administrator

Administrator — Sun, 27 Mar 2011 16:51:42 +0000

Because people would just ignore the . and the _. The moral equivalent happened with XML namespaces.

By: Lee

Lee — Wed, 02 Mar 2011 08:31:52 +0000

How would it fail if the object/property and namespace had the same name? For a name to be identified as a namespace a dot character or _ in my suggestion would first need to present which a normal name does not have.

By: Administrator

Administrator — Wed, 02 Mar 2011 04:25:55 +0000

Because they have no choice but to get it right. If they want to parse incoming data then they have to parse it with the full name. No shortcuts would work (other than position based which yes, people will do). With namespaces people just ignore the namespace and parse the names directly with the result that if you have name collision things just fail. By having every name be unique this isn’t an issue.

By: Lee

Lee — Tue, 01 Mar 2011 10:26:44 +0000

That might be easy but I don’t see how that would be better than the original purpose of namespaces.
People who use them badly are just amateurs and likely won’t have a server load big enough to be concerned with doing it right.

By: Administrator

Administrator — Tue, 01 Mar 2011 03:20:29 +0000

That’s indeed my proposal to easy processing.

By: Lee

Lee — Wed, 23 Feb 2011 17:53:38 +0000

The point in namespaces is to be templates that say what data is permitted and what value to give data that is not defined. From my understanding of what your trying to say is that the implementation should be changed to global objects rather than templates.

By: Administrator

Administrator — Wed, 23 Feb 2011 17:35:44 +0000

I think we are talking past each other. I understand that the JSON can be transformed. But it is my personal belief (I can’t prove I’m right) based on what I saw with XML that most people will screw up the namespace translation and as a consequence the namespace mechanism will fail in practice even though it should work in theory. That’s why I went for globally unique names instead since they require zero additional code, they just work, no effort required.