extension semantics and processing

[dret]

it seems that apart from the h vocabulary, all others are supposed to be optional, and will be defined by extensions. that's good, but in order to make processing hyper safe, it must be clear how to process any hyper instance.
one way to go would be to support robust extensibility (http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html), so that extensions are always safe to ignore. but if that's the goal, then hyper must require extensions to only have localized semantics: no extension can change the semantics of something outside their own scope, meaning that clients can ignore or process extensions, and will always be on the safe side.

[inadarei]

but if that's the goal, then hyper must require extensions to only have localized semantics: no extension can change the semantics of something outside their own scope, meaning that clients can ignore or process extensions, and will always be on the safe side.

Definitely the intention. And great point calling it out. Will think how to add corresponding text to the spec, but if you have a suggestion in a form of PR - that would be great.

Thank you!

[dret]

i could give it a shot iff the processing model becomes more clear. this relates to #13, which to me is still not clearly specifying how i can take any JSON, and then safely parse it into "definitely not hyper", "definitely hyper (core vocab, needs to satisfy all core vocab constraints)", and "potentially hyper (extension vocab, needs to satisfy whatever constraints the extension defines)". well-defined extensibility needs these two parts, but i think we first need to understand the basic parsing rules before we can have a more detailed look into the constraints that then are applied.