Closed rubensworks closed 4 years ago
Isn't this just the normal inheritance/overriding pattern then? Also, if the first "name" actually does get overridden (in your second example) it's value should change. 😃
Isn't this just the normal inheritance/overriding pattern then?
Yes, you're right.
The only reason for adding this example would be to clarify that @protected
can –next to creating a brand new protected term– also be used while redefining an (unprotected) term.
This was an open question for me after reading the section on @protected
in the spec, so it's possible that other people may have the same question.
so it's possible that other people may have the same question.
granted. But on the other hand, I'm concerned that too many examples would be counter productive, making the spec harder to read...
Usually, test cases serve to flesh out corner cases; although not visible in the spec, they do serve a good purpose for describing such behavior.
There may be one reason why this should be put into the BP document: the text does emphasize in §3.4 JSON array should assume that values in an array should be assumed as unordered. However, the value of @context
is different: order of contexts does count, and this is a good (albeit possibly a bit complex) example.
It shouldn't be too hard to develop an isolated example showing two simple contexts interact that way. I think it's a very good idea to show it, and not just tell people about it in the spec.
Is the desire here to feature an example with two contexts (as per @rubensworks' example above) that do and don't successfully override a definition, based on the ordering question? Is @rubensworks' example (perhaps with a different vocabulary) meet for that purpose immediately?
This issue was discussed in a meeting.
Following the discussion in https://github.com/w3c/json-ld-syntax/issues/153, it would be good to add an example to the BP document of non-trivial
@protected
usage that does not throw an error.The following (error-throwing) example is present in the syntax spec:
The following would be relevant to add as an example that does not throw an error, even though there is a term override happening: