Re: [Specifications] How to document forbidden dereferencability (#216)

> I don't think it's good approach. If client doesn't understand something, it should ignore it.

One does not contradict the other. If the server knows that a client won't understand IANA media types, it may chose omit them from the responses. If it doesn't then the client will indeed ignore them. Two sides of same coin.

> These are not profiles - these are extensions. I'd call profile something we could ebrace in spec.

👌  I'm fine with calling them extensions. We did in fact refer to "extensions points" in the past.

So profile would be closer to what you called `level` above?

> Anyway, lets get our discussion back to the topic - which solution and how could make it happen?

I repeat, I think that removing `rdfs:range` is the way to go. Explicit "negated dereferencability" is probably an overkill if you intend it on individual resources.

I have nothing against the profiles per se but I think it just adds unnecessary complexity to the client implementation to conditionally apply different reasoning for the different profiles.

In other words, I think it's enough that `hydra:Resource` will be the only way to explicitly state dereferencability. All of Hydra's terms are already as well as objects of `hydra:Link` properties. In practice this maye leave little room for actual breaking from such a change

-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/216#issuecomment-635781370 using your GitHub account

Received on Friday, 29 May 2020 06:12:54 UTC