Add discussion of TR 'Content Negotiation by Profile' #177
Conversation
| The <a data-cite="DX-PROF-CONNEG#requestsandresonses" | ||
| >operations of the abstract model</a> | ||
| are "list profiles" and "get resource by profile". | ||
| The "get resource" operation can provide the profile requests with HTTP | ||
| header <code>Accept-Profile</code> and responses use <code>Content-Profile</code>, or | ||
| alternatively the request can use HTTP Query String parameters. |
There was a problem hiding this comment.
How does this address the clear statement (I don't have the citation handy; sorry) that profiled media types are supposed to be subsets of the media type, i.e., << >> notation is not valid text/turtle regardless of the profile attached -- because << >> notation is not valid text/turtle!
There was a problem hiding this comment.
@TallTed I agree. However, the way I see it, a future working group could
- extend text/turtle to support turtle-star
- define different profiles for the text/turtle (with or without RDF-star, possibly others)
- define that the default profile SHOULD be "without RDF-star". Since old client will not require any profile, this would encourage servers to accommodate them if practical.
As Andy wrote, this does not solve the optimistic/pessimistic dilemma for us. But this should be considered by a future WG in the design of a durable solution.
There was a problem hiding this comment.
The negotiation is of information model and "profile" in that document is a "specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications."
That said, TR/dx-prof-conneg is of possible if text/turtle is updated. Media types are not immutable and other types have changed "in place" over the years or bypassed the media type issues and done their own thing (e.g. XML 1.1).
As we have identified, there is no perfect solution here. Each route has negative impact in some cases. Until we have field experience, we can't make a fact-based decision.
There was a problem hiding this comment.
That said,
TR/dx-prof-connegis [only] possible iftext/turtleis updated. Media types are not immutable and other types have changed "in place" over the years or bypassed the media type issues and done their own thing (e.g. XML 1.1).As we have identified, there is no perfect solution here. Each route has negative impact in some cases. Until we have field experience, we can't make a fact-based decision.
Fair enough. But since we can't make a fact-based decision, I submit that we should not make a decision at all, but rather list the possible options we know of, along with the pros and cons and additional requirements of each — such that it's clear that, for instance, TR/dx-prof-conneg could be brought into play (and solve our media type quandary) IFF text/turtle (and some other current media types) were also updated to have a profile which resulted in today's format and which was the effective profile when no profile was declared, along with such other profiles as were deemed needed/relevant at that point, such as (hopefully) profiles for RDF-star serializations, such as (the most relevant for this example) Turtle-star.
There was a problem hiding this comment.
I don't believe it makes a decision.
The section is "non-normative".
The new text says "This may be useful when the information is available in RDF-star or in non-RDF-star RDF 1.1 form," and refers back to the dilemma set out in the beginning of the section.
There was a problem hiding this comment.
A section being non-normative does not mean it will not be take as a strong suggestion, which can amount to a decision even though authors and editors and others loudly assert that it was not a decision.
I think that links back to these discussions/issues/PRs would be as appropriate, possibly more so, as the links to RFCs we're not deciding to use but suggesting as possibilities...
While minimizing the possibility of confusion, or suggestion of debate, or even word count, can sometimes be appropriate in WG Candidate or Proposed Recommendations, I do not think the same applies to CG Reports, especially where we (at least, I) anticipate significant discussion and conclusions that may or may not include any of the possibilities listed in the report, due to the anticipated (or at least hoped for) broader community participation.
Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>
|
This was discussed during yesterday's call: https://w3c.github.io/rdf-star/Minutes/2021-06-04.html#t06 |
This address #175.
Preview | Diff