"any JSON is hyper" claim #13
Comments
|
Ha! Well, mathematically speaking - you are correct. But as a Physics undergrad, I would argue that the real world doesn't operate in absolutes. There is no "absolute true" and "absolute false". The statement is just "true enough" :) That said, let's look at the reality and how "true enough" the claim is. Yes, obviously, Hyper establishes certain additional constraints on JSON, which is why its media type identifier is different from
an arbitrary JSON will never violate anything in Hyper. Which means that, if we didn't want to provide extensive examples, explanaitons etc. an RFC for Hyper would be just following rules:
That's it. The hypothetical RFC doesn't need to say anything else. Because Hyper is built on mixins (plus: core mixin) and not: inheritance. Which is way less than most other hypermedia formats can claim. And therefore the succinct explanation of this fact that you objected to. Yes, HAL comes close to the same claim (however: there's no other idiomatic place, besides the spec itself which defines what If you look at most other hypermedia types, however: Siren, JSONAPI, Collection+JSON, even UBER - they all have constrained shape and don't come nearly as close to the claim as Hyper does. So in relative, physics-terms, I do think Hyper lives up to its promise. That said, this is a valid question and we are trying to find a better way to explain in which approximation the claim is true, given how it is not true in absolute terms. Fair? |
|
On 2017-12-28 15:49, Irakli Nadareishvili wrote:
Ha! Well, mathematically speaking - you are correct. But as a Physics
undergrad, I would argue that the real world doesn't operate in
absolutes. There is no "absolute true" and "absolute false". The
statement is just "true enough" :)
is it? i was in fact talking about practical issues.
Yes, obviously, Hyper establishes certain additional constraints on
JSON, which is why its media type identifier is different from
|application/json| however it is valid to do following things:
1. You can write JSON object of nearly any shape
2. If you don't prefix your keys with "h:" prefix or make your
attributes be URIs that start with http://hyperjson.io/props/
an arbitrary JSON will never violate anything in Hyper.
what about if i have any other qnames as keys? will those be silently
accepted as "not hyper", or will they trigger a "curie not declared"
warning? or an error?
Which means that, if we didn't want to provide extensive examples,
explanaitons etc. an RFC for Hyper would be just following rules:
1. Hyper is a JSON of arbitrary shape.
2. Keys of a Hyper document MAY be URIs, optionally CURIEd. Such
attributes indicate extra semantics and processing rules that can be
provided by a resource at the other end of the URI, or elsewhere.
This is the primary way of extending Hyper.
i still think there's potential for trouble. mike tucked all his stuff
into one special place. that makes it safe. i am not quite clear when
exactly JSON data is supposed to be hyper (and checked for compliance
with the hyper constraints, i guess?), and when it just happens to look
like it, but was never intended as such. if you claim *all* qnames and
URIs to be off limits as keys, that's quite a significant value space.
if not, i'd like to see a clear definition of what value space exactly
might create conflicts with hyper.
3. Applications producing and consuming Hyper acknowledge the implicit
existence of a core set of extensions, that is documented at URIs,
the root of which is http://hyperjson.io/props/
sure. but don't you claim that for *all* hyper and not just the core
vocabulary? this is where i still feel some magic happening.
That's it. The hypothetical RFC doesn't need to say anything else.
Because Hyper is built on mixins (plus: core mixin) and not:
inheritance. Which is way less than /most/ other hypermedia formats can
claim. And therefore the succinct explanation of this fact that you
objected to.
hm. i guess i must be missing something, then. i still cannot see how
the mixin model and its open namespace of both URIs and qnames allows
this to happen.
Yes, HAL comes close to the same claim (however: there's no other
idiomatic place, besides the spec itself which defines what |_links| and
|_embedded| are and/or what attributes and shapes they can have, so HAL
/is/ further than Hyper). If Mike Kelly wants to make the same claim as
Hyper does - he's more than welcome to.
i think he's in a better position, actually, because he tucked
everything away in a few reserved places. maybe that's not
super-elegant, but that's just dealing with JSON's existential ugliness
as an open data format.
If you look at most other hypermedia types, however: Siren, JSONAPI,
Collection+JSON, even UBER - they all have constrained shape and don't
come nearly as close to the claim as Hyper does.
true. i never saw this as a great feature, though. mike talks a lot
about it, and i am sure it's a kind of a good selling point for people
who don't actually *want* to do hypermedia. beyond that, i am not so sure.
So in relative, physics-terms, I do think Hyper lives up to its promise.
i'll re-read the spec once clarified and might come up with a few
examples to poke around a little.
That said, this is a valid question and we are trying to find a better
way to explain /in which approximation/ the claim is true, given how it
is not true in absolute terms. Fair?
as i said, i think you may be underestimating the real estate in value
space you're giving away for keys by all possible using qnames and URIs
(because you never know what mixins are doing, right?).
|
|
“I still think there's potential for trouble. mike tucked all his stuff into one special place. that makes it safe“ @inadarei this is, I think, the same argument I was making when I talked about mixing data and metadata. It’s just a lot simpler to segregate format-specific data into one place. Given the freedom of a HAL Resource to show up anywhere, I’m not sure that HAL is much better in this regard, as long as we only squat on h:* keys, as Kelly did on _* keys. |
@randallsquared since most hypermedia formats that "don't mix data and metadata" do support recursion of some sort (otherwise they would have very limited scope, like in case of Collection+JSON) – metadata is still sprinkled all over the place, so I don't see any fundamental gains in simplicity here. What I do see is - significantly increased verbosity and complexity due to recursion. I believe the tradeoff here is: "is this simple for whoever parses the document, or whoever designs messages, using this format". And Hyper prioritizes the simplicity of the latter. Regardless - seggragated data vs. metadata is simply not the design of Hyper, and if such approach is preferred, the choices are already abundant. |
AFAIK a "qname" is a form of a CURIE, so - I am not sure what you are asking. If you are asking: "what if I have a key with a colon in the name, but it does not start with There is no magic here:
In any API, for any attribute in any message - consumer derives semantic meaning of that attribute based on:
This is as true for Hyper as it is for anybody else. The difference in Hyper is, it allows a way to provide in-band semantic hints by letting:
be URIs. And by declaring core That's it |
|
Spec updated per discussion here: http://hyperjson.io/spec.html#design-choices I hope it addresses your concerns much better than the original did. |
|
On 2017-12-30 06:15, Irakli Nadareishvili wrote:
AFAIK a "qname" is a form of a CURIE, so - I am not sure what you are
asking. If you are asking: "what if I have a key with a colon in the
name, but it does not start with |h:| (default CURIE) and is not
declared explicitly as a CURIE in |h:head.curies|" – the answer is: then
you just have an attribute whose name contains a colon. It may still be
a URI if the part before the colon defines some known URI protocol (e.g.
|data:|) but it is not a CURIE.
ok then. this means you define being a CURIE as a function of being a
qname *and* the prefix being declared per hyper. that's fine i guess (i
have to think about it a bit), but that's something that needs to be
made explicit.
There is no magic here:
1. An attribute MAY be a URI
the key or the value, or both? the way you use CURIE is not as well
defined as it should be. if the prefix declarations per hyper
exclusively apply to property keys (and i am just guessing here), this
needs to be made explicit. if not, then say exactly what they apply to.
2. If an attribute is a URI, it MAY be CURIEd (and will be treated as a
CURIE if it is the default |h:| CURIE or is explicitly declared as a
CURIE by documenting in |h:head.curies|)
JSON has no attributes. it has objects with members, which have
names/keys, and values. i am really not clear about what you mean by "an
attribute is a URI".
3. If an attribute is a URI, documentation for additional semantics MAY
be provided as a resource at the other end of that URI.
that seems to speak about the member keys.
This is as true for Hyper as it is for anybody else. The difference in
Hyper is, it allows a way to provide in-band semantic hints by letting:
1. Attributes
2. h:type and
3. rel
be URIs. And by declaring core |h:| vocabulary it avoids the need to
have hardcoded structure.
i'd switch all of this to standard JSON terminology, and to also be very
clear about the scope (just member keys in the top-level object, any
member keys anywhere, or maybe values beyond member keys as well).
|
|
On 2017-12-30 06:44, Irakli Nadareishvili wrote:
Spec updated per discussion here:
http://hyperjson.io/spec.html#design-choices
I hope it addresses your concerns much better than the original did.
wouldn't you need to include that any content that looks like hyper
(i.e., it has CURIE member names), but doesn't follow the constraints of
the specific hyper module, has no hyper semantics and has to be ignored
for the purpose of any hyper processing? otherwise you'd end up with
"hyper errors" for perfectly fine JSON documents, which seems to be
something that you want to avoid?
|
Everywhere I say "attribute" I mean a key of a JSON object. |
|
On 2017-12-30 11:45, Irakli Nadareishvili wrote:
JSON has no attributes. it has objects with members, which have
names/keys, and values. i am really not clear about what you mean by "an
attribute is a URI".
Everywhere I say "attribute" I mean a key of a JSON object.
i think you actually mean the key of a member of a JSON object?
https://tools.ietf.org/html/rfc8259#section-4
|
|
:) wel, yes. Based on that ABNF, it is called " |
|
On 2017-12-30 11:57, Irakli Nadareishvili wrote:
:) well based on that ABNF, it is called "|string name| of a member of a
JSON object. But that is 5 words instead of "an attribute" so I am a bit
hesitant doing a 'find replace" and using that many words :)
i'll get used to it over time, i guess. it's mostly that "attribute" is
not a term at all in JSON-land, so that's a bit odd.
|
|
Understood. But calling 'attribute' the name of a data member of an object, in general, is a common thing (as you said - not necessarily in JSON RFC). Edited spec to define the terminology early on, and thus remove ambiguity:
|
|
so, did we make any progress on the fundamentals of this? the question still is open how the processing model treat member names/values when they syntactically match hyper's rules, but semantically don't. |
that claim is outright magical and needs to be detailed. in any JSON format i've ever seen, a format puts constraints on how to use JSON. these constraints can be in the form of a schema, or the form of a spec.
i can see how JSON not containing hyper properties can be hyper. that's pretty much the HAL approach to allow plain JSON.
however, as soon as there is data that's mixed in that claims to be hyper, it seems outlandish that every possible JSON data you put in these properties is valid hyper. the spec has a lot of constraints how to use properties. what happens if those constraints are not satisfied? per the claim, that would still need to be valid hyper and thus those constraints have to be removed because every possible value must have a valid hyper interpretation.
as mentioned, the claim as it is made seems magical, and needs a lot of explanation in order to explain to people that as a logical conclusion of that claim, there is no such thing as invalid hyper.
The text was updated successfully, but these errors were encountered: