-
Notifications
You must be signed in to change notification settings - Fork 8
Should the non json-ld version have an @context
#7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I agree with your last sentence. I think it would be a good precedent to set to allow possible paths. Path 1 would be plain old JSON, unambiguously JSON (when we correct that signature). Path 2 would be valid JSON-LD. The only question then is how would interop work? Would there be a preprocessor to de-LD-ify a path 2 schema? Would there be a preprocessor to LD-ify a path 1 schema? Or, would the spec require that publishing a schema results in publishing two documents. I do not think including a context should be a requirement for those who do not wish to use LD. In the Workday ecosystem, our DID Documents have the requisite LD properties since we have no other choice when complying with the spec, even though we do not use LD. The DID Spec explicitly requires a context property, even though it is only a recommendation that...
|
AFAIK there won't be interop without the none JSON-LD users accepting a context which they ignore. JSON-LD is stricter than json, so if you want interop with it, you need at least the Given that we can add this one field and be guaranteed that the vc-json-schema can be used by both JSON-LD and regular JSON users, and we would be handling things the same way as the DID Spec and VC Spec, there is some historical bias to including the context for non JSON-LD users. |
this is the sticking point, isn't it. I don't see a way around it that isn't unfriendly to the users, so I think it is the best move. |
I have been swayed by some of the discussion in w3c/did#142 (comment) and I think we should follow their lead. And your comment, Orie
If this is a current understanding, then the context property can be optional and signifies intent on how the document should be parsed |
Related to #122; more discussion needed |
Removed entirely. Can be wrapped as a credential if needed. See #131 |
The DID Spec and the VC Data Model both have mandatory
@context
fields, which make it clear that these documents may support JSON-LD.It seems likely that we should do the same thing here.
However, I have started with the assumption that those wishing to use these vc-json-schema documents do not understand JSON-LD nor will they tolerate extra parameters that are only required for JSON-LD interop.
Since we provide a demonstration of both ways to do things, its clearly possible to signal your intent to use JSON-LD by using the
@context
version, or not.The text was updated successfully, but these errors were encountered: