search

RubenVerborgh / Hydra-Architecture-Diagram

6 stars 2 forks source link

Non-RDF bodies #4

Open tpluscode opened 7 years ago

tpluscode commented 7 years ago

I would add non-RDF media types to the Entity Bodies section. And maybe also multipart requests.

I think it's important to support not only RDF given that it seemed a fairly common topic raised on the mailing list.

RubenVerborgh commented 7 years ago

Done in 8c4dcdeee4d3c4e6dda928f6f953e455c8cee089, but I'm looking for a positive term perhaps, as "non-RDF" probably still smells too much like "RDF".

tpluscode commented 7 years ago

@asbjornu @lanthaler, thoughts?

asbjornu commented 7 years ago

How about "POJO" or simply just "JSON"?

RubenVerborgh commented 7 years ago

It used to say "JSON", but I wonder if @tpluscode's intention was also to go beyond JSON. (images?)

tpluscode commented 7 years ago

Images too. But there are plenty of other formats. csv, pdf or some vendor-specific XML flavors like XBRL and whatnot.

Now that think about that and look at the Bodies section I think that maybe the first sentence is not the whole story either

Entity Bodies express field values are combined into an request body

With some formats you may not have fields at all. And again, multipart file uploads.

asbjornu commented 7 years ago

But is it within the scope of Hydra to define the behaviour of all of these different content types?

RubenVerborgh commented 7 years ago

Just for clarity, here's the version without typos (1235eb52ee5617a2bd4545e864fc8126aa391078):

Entity Bodies express how field values are combined into a request body

With some formats you may not have fields at all. And again, multipart file uploads.

I intended to be very liberal here. A file is a field. I can make this explicit.

In the most broad sense, I aim to say that it defines how user/client input of whatever kind is translated into the body of the request. I use the "Field" terminology to align with the Fields package in the architectural diagram (which would become quite abstract when named "Input"). However, the definition of Fields is very generically "places where clients can provide input."

So summarizing, the intent is definitely there and aligns, but the language might not make this clear yet. Suggestions welcome.

But is it within the scope of Hydra to define the behaviour of all of these different content types?

I'd say no. It is within the scope of the Hydra Core Vocabulary to provide an extensible mechanism for doing so, and perhaps to define it for JSON(-LD).

asbjornu commented 7 years ago

I see. Perhaps an analogy to HTML's <input type="file"> et al would make the "field" concept easier to grok?

It is within the scope of the Hydra Core Vocabulary to provide an extensible mechanism for doing so, and perhaps to define it for JSON(-LD).

I agree.