Re: Replace hydra:Error with application/problem+json

2015-09-29 9:23 GMT+02:00 Mark Nottingham <mnot@mnot.net>:

> We're post-LC and the WG has very little energy for more changes.
> I'd suggest that if someone wanted to do this, they could easily do
> so in a separate document.

I wasn't aware of the draft's status. Since it's post LC, that's
indeed the natural thing to do.

2015-09-29 22:33 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>:

> On 26 Sep 2015 at 13:15, Dietrich Schulten wrote:
>> +1 that we should attempt to integrate with problem+json as close as
>> possible.
>
> While I generally agree that integrating different standards is desirable
> and worth the effort, I struggle to see the advantages in this case.

The advantage is recognition and compatibility. If (and I expect this
to be the case), problem+json gets a lot more recognition,
implementations and visibility on the web in the years to come, Hydra
will make its "Error" type easier to integrate with and understand for
anyone who've come across problem+json if it's compatible than if it
isn't.

> application/problem+json and JSON-LD/Hydra have completely different
> processing models, so just making there structure and property names
> look the same (which in JSON-LD you can't guarantee that anyway) doesn't
> change much.

It changes the bytes on the wire from something strange and unfamiliar
to something known and familiar. While JSON-LD makes it possible to
map this familiarity to something completely arbitrary and random,
that doesn't mean the default shouldn't be as close to problem+json as
possible, imho.

> I don't expect there to be that many clients that will understand
> problem+json but not Hydra and interact with a Hydra-powered
> Web API... or vice versa for that matter.

Why let that expectation destroy any possibility of interoperability
between problem+json and Hydra?

As with JSON-LD, I think the most important aspect of Hydra is *not*
that it can describe RDF graphs, but that it solves real problems for
people who aren't Semantic Web Scentists. And for those people (like
me), what matters most is how the JSON looks like and what we can do
with it with as little investment as possible.

Not having to know RDF but still be able to produce something that can
be consumed by an RDF bot is super powerful, but it's not the major
feature I expect people will look to Hydra to solve. To them, and me,
Hydra is the WSDL of REST.

> For those reasons, I don't think it makes sense to delay the
> publication of problem+json any further.

That's something I can agree with.

> Let it be published and we will see whether it will be adopted.

Do we have to wait for adoption to make hydra:Error compatible with
problem+json? Why?

> If not, we don't have to think about alignment anymore. If it
> will be widely adopted, we still have the luxury to be able to
> change Hydra.

Not if Hydra is a published W3C Recommendation before we align it with
problem+json. Will creating a GitHub issue on this ensure that the
specification isn't considered complete until the issue is resolved?
If so, I'll create one.

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Thursday, 1 October 2015 08:22:13 UTC