manton
Why allow non-string values for a feed's id?
The spec says
If an
idis presented as a number or other type, a JSON Feed reader must coerce it to a string.
If you have a moment to explain, I'd love to understand the motivation for allowing other types in this place at all. So far, to me, it seems like an unnecessary complication.
It would be easier (for me) to reject a feed as invalid if it has anything other than a string there.
It wouldn't be so hard if I wanted to convert whatever value shows up while decoding, and then treat it as a string from then on, but I'm also trying to consider software that needs to both decode and then encode again. For example, an aggregator. Presumably it should faithfully encode whatever value was in the original file, even if it wasn't a string. That means I can't just make the internal representation be string, I have to make it be anything. In that case, accessing the string form of the id is less convenient for a client of my library. Instead of just item.id it would have to be something like item.id.toString().
Now this isn't the end of the world but it is a downside. My question is: what's the upside? Why is this in the spec?
(Usually the advice I give when considering this sort of thing is: it's much easier to add things than to take them out. In fact, for JSON Feed it's impossible to take them out. So if there's any doubt, it's better to make the spec more restrictive to start with. In this case that would mean saying it's required to be a string. If there's lots of demand for non-string ids in the future, then maybe that can be added. I'm not trying to argue for that here because I think it's probably too late. This is more of just a question so I (and others) can understand the reasoning behind this. Apologies if this isn't the right place to ask.)
Presumably it should faithfully encode whatever value was in the original file, even if it wasn't a string.
Actually, is this true? Would it be reasonable to generate a whole new id for every item in the aggregate feed? I am not sure.
I was also surprised by this part of the spec and also didn’t immediately realize that id doesn’t have to be a string. For one, it clearly states string in the beginning: “id (required, string) is unique …”. Furthermore, “presented as a number or other type” is a little bit vague, in my opinion.
If JSON Feed really does accept any type for item.id, I’d suggest clarifying the wording a bit.
Clarifying the wording here makes sense to me too. id really should always be a string.
Am I correct in interpreting this as another case of Postel’s Law, i.e., a parser shouldn’t fail over this but a validator would complain?
idreally should always be a string.
In that case, can I appeal to you to remove the "must coerce" wording as part of the clarification?
There's one sentence already in the spec, "If a feed is invalid JSON, then we strongly recommend not attempting to parse it or use partial data. You can’t rely on it." I think the principle behind this is 100% A+ spot on, and I only wish it went beyond merely invalid JSON to anything that doesn't fit the rules of the JSON Feed spec (such as something with a numeric id, but still valid JSON).
As a software author, I'd much prefer to have only two possibilities: it's a valid feed, and I can accept it, or it's invalid and I reject it. It's less awesome to have a third, "this feed is invalid, but it should still be accepted, and 'coerced' to a valid feed by some rule". That is pretty confusing — is it valid or not?
Am I correct in interpreting this as another case of Postel’s Law, i.e., a parser shouldn’t fail over this but a validator would complain?
Not to get too offtopic, but this is not the sort of thing that Postel meant, and IMO it should not be encouraged.
See https://groups.google.com/forum/#!msg/comp.mail.pine/E5ojND1L4u8/iYunDY6h_xMJ:
Pine seems to be the only mail or news program that refuses to decode [a particular invalid message]. All others are more liberal in what they accept. Should not Pine also be liberal in what it accepts?
This statement is based upon a terrible misunderstand [sic] of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software.
Jon's principle could perhaps be more accurately stated as "in general, only a subset of a protocol is actually used in real life. So, you should be conservative and only generate that subset. However, you should also be liberal and accept everything that the protocol permits, even if it appears that nobody will ever use it."
Converting an invalid feed to something "reasonable" is good for the user experience in individual cases in the short term, but terrible for the ecosystem in the long term.
In that case, can I appeal to you to remove the "must coerce" wording as part of the clarification?
I’m also in favor of this 👍
Not to get too offtopic, but this is not the sort of thing that Postel meant, and IMO it should not be encouraged.
To avoid derailing, I won’t delve into this but thank you for mentioning it. I’ll keep it in mind.
