Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarification of weak validators #163

Closed
reschke opened this issue Oct 18, 2018 · 6 comments
Closed

clarification of weak validators #163

reschke opened this issue Oct 18, 2018 · 6 comments

Comments

@reschke
Copy link
Contributor

reschke commented Oct 18, 2018

See https://www.rfc-editor.org/errata/eid5236

@reschke
Copy link
Contributor Author

reschke commented Oct 18, 2018

@mnot
Copy link
Member

mnot commented Sep 3, 2019

Not sure any change is necessary here.

@tfpauly
Copy link

tfpauly commented Nov 18, 2019

Discussed in Singapore; agreed to close this with no action, but @martinthomson offered to check if the text around validators could be clarified.

@martinthomson
Copy link
Contributor

Just to close the loop on this, the document is entirely precise and perfectly obtuse at the same time.

It says that the validator applies to the selected representation. So following the reference to Section 6 I find that the definition of selected representation correctly captures all the nuance, but fails to provide the easy cognitive shortcut of "selected representation =~ message body". It manages to effectively obfuscate things by not clearly distinguishing between serialization and the abstract concept of what the resource state is.

I believe that selected representation is the specific projection of the platonic resource into bytes. However, it doesn't really say that, it says that you interpret "bits" through the dual filters of content type and content coding. Using "bits" is unfortunate. XML schema has the dual notions of "value space" (the abstract form) and "lexical space" (the encoded form) and is very careful about being clear about which applies in which context. This is not clear in the same way.

For instance, the idea that a representation is an abstraction (as stated) is something I find quite confusing. The selected representation is a concrete form, expressed as a sequence of bytes. That representation might be conveyed on the wire (a GET response sometimes, a PUT request) or it might be acted on or referred to. Some methods operate exclusively on the bytes of a selected representation, even if those bytes don't hit the wire.

In short, the spec is correct, but it doesn't do a great job of teaching the protocol.

@mnot
Copy link
Member

mnot commented Feb 3, 2020

As that's a more general issue, closing in favour of #294.

@mnot mnot closed this as completed Feb 3, 2020
@reschke
Copy link
Contributor Author

reschke commented Aug 20, 2020

So should we reject https://www.rfc-editor.org/errata/eid5236 then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants