Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/386
First off. Thank you for doing this. Here are some notes.
1. The term is "namespace" not "domain." In case that terminology is used
in the documentation and not just in the PR notes.
2. Why do we have `@class` and `@type`. Seems we should just pick one. And
if the answer is cause `@class` is for Java object mapping infrastructure, that
isn't good and we will also use GraphSON to create `Vertex` objects in Python
and it might use UUID for its ID as well. Thus, `@class=UUID` is perhaps
`@type=UUID`. That is, if an object is "typed" its `@type` and the resolver
(for that language) will have to map the correct class.
3. I read your notes, but its still not clear to me. Why do we have
`@value`? I think we only need `@type` (or `@class`) and then the rest of the
JSON object data is up to the type serializer/deserializer. For instance, in
`Bytecode` (TINKEROP-1278) we have `@type=Lambda` and then `value`, `language`,
`arguments`. That is, there are 3 "values" we need to make the object and thus
`@value` shouldn't be special with a `@`. Plus, we save a char.
4. I think we can save some bytes and still be readable if we make our
namespace `g` instead of `gremlin`. Moreover, we should be consistent in our
naming convention and either use some standard JSON naming or default to Java
naming -- e.g. `g:vertexProperty`. Or better yet, if its NOT namespaced, its
assumed to be "Gremlin". That is, TinkerPop owns `vertex`, `vertexProperty`,
`edge`. You want to do something else -- its `myapp:vertex`. This also means we
own `uuid`, `int64`, etc. etc.
Thanks again for the extensive work.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
