Add support for describing headers#185
Conversation
… with na operation
angelo-v
left a comment
angelo-v
left a comment
There was a problem hiding this comment.
I would prefer to have a textual explanation and usage examples in addition to the JSON-LD changes.
| "@id": "hydra:IriTemplate", | ||
| "@type": "hydra:Class", | ||
| "subClassOf": "hydra:Resource", | ||
| "subClassOf": ["hydra:Template", "hydra:Resource"], |
There was a problem hiding this comment.
Do we need to mention hydra:Resource here? A hydra:Template is a hydra:Class is a hydra:Resource.
There was a problem hiding this comment.
I did not typed hydra:Template as any of the hydra types, thus to maintain backward compatibility, we have to point to hydra:Resource directly.
tpluscode
left a comment
tpluscode
left a comment
There was a problem hiding this comment.
I would prefer to have a textual explanation and usage examples in addition to the JSON-LD changes.
I concur. Even more, I'd say that we should first discuss the needs and requirements for these and other changes.
Like I said in #182, I think it should be a hard rule to first come up with an issue detailing what and why we need and only then attempt any changes to the specification.
| "label": "Template", | ||
| "comment": "Some abstract template.", | ||
| "vs:term_status": "testing" | ||
| }, |
There was a problem hiding this comment.
I'd like to challenge the very need for an abstract template. It sounds like smuggling OOP terminology into the vocabulary which strikes me as awkward
There was a problem hiding this comment.
I'm opened for alternatives.
This approach is to have backward compatibility and ability to use hydra:template on both hydra:IriTemplate and newly introduced hydra:HeaderTemplate.
Another approach would be to introduce completely new hydra:template alternative for hydra:HeaderTemplate. I think it would be prone to errors.
Yet another approach would be to completely remove header templates at all. I believe templates could cover more complex header value scenarios, i.e. those for PREFER, where you provide some complex expressions that could be bound to variables.
| "@id": "hydra:IriTemplate", | ||
| "@type": "hydra:Class", | ||
| "subClassOf": "hydra:Resource", | ||
| "subClassOf": ["hydra:Template", "hydra:Resource"], |
There was a problem hiding this comment.
In my opinion the weirder part is actually introducing inheritance here. IriTemplate is not just any string template. It is meant as implementing the rfc6570. The changes here make the relation with its original RFC... complicated.
There was a problem hiding this comment.
rfc6570 is just the default:
The literal's datatype indicates the template syntax; if not specified, hydra:Rfc6570Template is assumed.
And this quote only describes the hydra:template property, not the hydra:IriTemplate
Nevertheless I also have a bad feeling with this type of inheritance.
There was a problem hiding this comment.
Yep, RFC 6570 is not directly bound to IriTemplate. In RDF representation of hydra spec it is connected only via seeAlso, thus no strict data type is enforced.
| "label": "mapping", | ||
| "comment": "A variable-to-property mapping of the IRI template.", | ||
| "domain": "hydra:IriTemplate", | ||
| "domain": "hydra:Template", |
There was a problem hiding this comment.
Regardless of the other template changes, I think this should remain an IRI Template.
Or to test the logic, does it make sense to have a HeaderTemplate used with rdf:Property?
There was a problem hiding this comment.
Well, the hydra:HeaderTemplate would also need a hydra:mapping. I've just noticed that the range should be also decoupled from IriTemplateMapping.
The thing is, IriTemplate implies ... an IRI, which is not the case here. For headers (or body in future??) that would be completely different templating mechanism (i.e. razor :P)
| "vs:term_status": "testing" | ||
| }, | ||
| { | ||
| "@id": "hydra:HeaderTemplate", |
There was a problem hiding this comment.
Still on the subject of headers, I think we're reinventing the wheel here.
What do you think about adopting the structure and terminology from actual HTTP spec to describe the headers?
There was a problem hiding this comment.
This has been discussed already: #109
It seems that using unmaintained vocabulary that would in addition tightly couple hydra to a specific protocol is not a good idea. Hydra is meant to be protocol-agnostic, thus I don't see any option of using such vocabularies in the spec. -- #109 (comment)
Regarding this, should we support the description of (HTTP) Headers anyway?
There was a problem hiding this comment.
Sorry, I did not mean to propose the HTTP vocabulary. Just to follow the actual protocol specification to describe headers
There was a problem hiding this comment.
Sorry, misinterpreted that, should have followed the link ^^
There was a problem hiding this comment.
The idea with template in headers was to allow server to provide i.e. complete request template, including headers and/or body so the client just binds that template with variable values and sends back.
…is might ba an overkill. Added specification paragraphs related to headers.
…to issue/99_Add_support_for_describing_headers
tpluscode
left a comment
tpluscode
left a comment
There was a problem hiding this comment.
@alien-mcl as discussed on the call, please fix line endings in core.jsonld
…to issue/99_Add_support_for_describing_headers
|
LGTM |
3 participants
This is a derivative of a PR #182 that covers #99 :