Repository navigation
Lexicon: do fields with string formats allow empty string values? #3833
|
Hi all! Quick schema validation question: if a string field in a lexicon has a string format specified, is the empty string ever a valid value for that field? ie if the field is provided with value ...and maybe more generally, are there times when we should maybe be more lenient and accept inputs even if they may technically be invalid, like this? Should we be more lenient with query params than record data? Any other relevant cases? (Ie, Postel was right? Postel was wrong? 😆) @whyrusleeping and I debugged this a bit recently, he was using an SDK that evidently included all params in XPRC methods, and defaulted string params to the empty string, which Bridgy Fed complained about for params with string formats, eg Minor, I know. Thanks in advance! |
Replies: 1 comment 2 replies
|
From a protocol standpoint, I think no: if a string format is specified, the empty string should not pass validation and the request / record should be rejected. We should fix our go code which is incorrectly sending around empty strings. There are some difficult corner-cases around JSON, but this is not one of them. Without weighing in on Postel in general, I think the entire atproto ecosystem should try to stay as consistent as possible about lexicon validation. It is hard to be consistent with multiple implementations, so everybody should try to be consistent with the written specification; if there is a major problem between implementation and the written specs we should get them aligned however possible. |
From a protocol standpoint, I think no: if a string format is specified, the empty string should not pass validation and the request / record should be rejected. We should fix our go code which is incorrectly sending around empty strings. There are some difficult corner-cases around JSON, but this is not one of them.
Without weighing in on Postel in general, I think the entire atproto ecosystem should try to stay as consistent as possible about lexicon validation. It is hard to be consistent with multiple implementations, so everybody should try to be consistent with the written specification; if there is a major problem between implementation and the written specs we should get them alig…