{"action":"created","issue":{"url":"https://api.github.com/repos/json-api/json-api/issues/850","labels_url":"https://api.github.com/repos/json-api/json-api/issues/850/labels{/name}","comments_url":"https://api.github.com/repos/json-api/json-api/issues/850/comments","events_url":"https://api.github.com/repos/json-api/json-api/issues/850/events","html_url":"https://github.com/json-api/json-api/issues/850","id":102266479,"number":850,"title":"Recommendation for dasherizing (kebab-case-ing) namespaced object, such as `Admin::User`","user":{"login":"bf4","id":142914,"avatar_url":"https://avatars.githubusercontent.com/u/142914?v=3","gravatar_id":"","url":"https://api.github.com/users/bf4","html_url":"https://github.com/bf4","followers_url":"https://api.github.com/users/bf4/followers","following_url":"https://api.github.com/users/bf4/following{/other_user}","gists_url":"https://api.github.com/users/bf4/gists{/gist_id}","starred_url":"https://api.github.com/users/bf4/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bf4/subscriptions","organizations_url":"https://api.github.com/users/bf4/orgs","repos_url":"https://api.github.com/users/bf4/repos","events_url":"https://api.github.com/users/bf4/events{/privacy}","received_events_url":"https://api.github.com/users/bf4/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2015-08-21T00:16:38Z","updated_at":"2015-12-20T10:04:16Z","closed_at":null,"body":"JSON API recommends dasherized keys, so an `AdminUser` would be represented by `admin-user`. But, does/should JSON API have an opinion on namespaced objects? That `Admin::User` would be dasherized as `admin/user`?  (That's the result in Rails of `\"Admin::User\".underscore.dasherize`)"},"comment":{"url":"https://api.github.com/repos/json-api/json-api/issues/comments/166101037","html_url":"https://github.com/json-api/json-api/issues/850#issuecomment-166101037","issue_url":"https://api.github.com/repos/json-api/json-api/issues/850","id":166101037,"user":{"login":"ianzepp","id":757705,"avatar_url":"https://avatars.githubusercontent.com/u/757705?v=3","gravatar_id":"","url":"https://api.github.com/users/ianzepp","html_url":"https://github.com/ianzepp","followers_url":"https://api.github.com/users/ianzepp/followers","following_url":"https://api.github.com/users/ianzepp/following{/other_user}","gists_url":"https://api.github.com/users/ianzepp/gists{/gist_id}","starred_url":"https://api.github.com/users/ianzepp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ianzepp/subscriptions","organizations_url":"https://api.github.com/users/ianzepp/orgs","repos_url":"https://api.github.com/users/ianzepp/repos","events_url":"https://api.github.com/users/ianzepp/events{/privacy}","received_events_url":"https://api.github.com/users/ianzepp/received_events","type":"User","site_admin":false},"created_at":"2015-12-20T10:04:16Z","updated_at":"2015-12-20T10:04:16Z","body":"I'd like to chime in here as well, as I am dealing with the issue of namespaced JSON for a platform project.. To summarize the issue:\r\n\r\n- Client installs a core object type from a public package (let's call it an `Account`).\r\n- The Account object comes with a number of predefined properties, created by the package publisher. Each property needs to be logically in its own namespace. So for a property named `FirstName` we are looking at doing something like `Publisher:FirstName` as the JSON key name.\r\n- On the client/subscriber side of things, the client needs to be able to extend the core object with their own properties (such as `MiddleName`). However, we need to ensure that the property name in the JSON object doesn't conflict with any property names from the original publisher. As a result, we are allowing clients to establish their own namespaces for their instances and/or to use a predefined global such as `Local` as the namespace.\r\n- Finally, the namespacing needs to allow for additional future extensions to the object type from later package installs, that themselves may have extended the objects with unique (but potentially clashing) property names.\r\n\r\nFor us, the separator of choice seems to be a single colon, so we are ending up with JSON structures such as this:\r\n\r\n```\r\n{\r\n  \"id\": \"4jqhbsf3ej43bjfn\",\r\n  \"core:description\": null,\r\n  \"core:endpoint\": \"observers\",\r\n  \"core:prefix\": null,\r\n  \"core:suffix\": null,\r\n  \"core:frozen\": false,\r\n  \"core:stability\": null,\r\n  \"core:restricted\": false,\r\n  \"core:static\": false,\r\n  \"core:immutable\": false,\r\n  \"core:cacheable\": true,\r\n  \"core:leaky\": true,\r\n  \"core:metadata\": true,\r\n  \"core:name\": \"Observer\",\r\n  \"core:visibility\": \"global\",\r\n  \"core-ui:icon\": \"fa-eye\",\r\n  \"core-ui:label\": \"Observer\",\r\n  \"core-ui:pluralLabel\": \"Observers\",\r\n  \"db:namespaceId\": \"n0000000\",\r\n  \"db:schemaId\": \"Schema\",\r\n  \"db:createdDate\": \"2015-11-23T23:06:19.438Z\",\r\n  \"db:createdById\": \"ekx4clbn\",\r\n  \"db:updatedDate\": \"2015-12-09T22:23:55.565Z\",\r\n  \"db:updatedById\": \"e1qnq2kvekxmex2j\",\r\n  \"db:managedDate\": \"2015-11-23T23:06:19.438Z\",\r\n  \"db:managedById\": \"ekx4clbn\",\r\n  \"db:managed\": true,\r\n  \"db:trashed\": false,\r\n  \"db:deleted\": false,\r\n  \"db:published\": false,\r\n  \"core-sharing:read\": \"*\",\r\n  \"core-sharing:edit\": \"*\",\r\n  \"core-sharing:hide\": \"\",\r\n  \"meta:editable\": true\r\n}\r\n```\r\n\r\nIn this example, `core`, `core-ui`, and `core-sharing` are all packages which may or may not be installed, based on the subscriber's choice. The `db:*` package wraps the underlying database metadata, and the `meta:*` package is on-the-fly calculations of runtime-scope-specific metadata."}}