Namespaces

From The Socknet

This document describes a valuable technique in XML that can be applied to JSON.

XML contains a feature called namespaces which enables nodes with names that would otherwise be the same to be differentiated. That system requires a shorthand namespace code and a unique string to define the namespace. That unique string is usually a URL. It looks like this:

<shortHand:realName xmlns:shortHand="http://the-actual-namespace.com/" />

We can reuse this concept in JSON but without the short-hand form. Instead, we fully-qualify our fields with domain names.

If you extend the Socknet by creating a function or a new field for an existing fnction, you may use the following technique to name it.

If your field's name is fieldName and the namespace you'd like to use is foomor.org, then your field's name can be foomor.org:fieldName.

If you want to use the reverse namespace org.foomor as is common in many programming languages, that's good too: org.foomor:fieldName

Example:

If you intended to extend the post-message function to accept a field called org.foomor:xyz it would look like this:

POST post_message
{ from: ...
  message: ...
  "org.foomor:xyz": 1337
}

And the receiving party would read it something like this:

$xyz = $posted_data['org.foomor:xyz']

These same concepts can and should be applied to function names.

Nobody will use my function if they have to type so much!

Yes they will.

Considerations

Encoding/decoding URI paths is not handled uniformly in all web framework packages, so it is best to avoid using characters that need encoding in function names. The example given here uses only alphanumerics, dots (.), and colons (:), none of which needs encoding, so this form is recommended.

Specifically, some frameworks do not handle /'s properly, so they should never be used.