Non-RDF bodies

[tpluscode]

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]

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

[tpluscode]

@asbjornu @lanthaler, thoughts?

[asbjornu]

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

[RubenVerborgh]

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

[tpluscode]

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]

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

[RubenVerborgh]

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

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]

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.