Should `Content` use an enum to differentiate between `src` and `value`?
Appreciate the library!
RFC 4287 notes:
atom:content MAY have a "src" attribute, whose value MUST be an IRI reference RFC3987. If the "src" attribute is present, atom:content MUST be empty.
The current structure of Content is:
pub struct Content {
/// Base URL for resolving any relative references found in the element.
pub base: Option<String>,
/// Indicates the natural language for the element.
pub lang: Option<String>,
/// The text value of the content.
pub value: Option<String>,
/// The URI of where the content can be found.
pub src: Option<String>,
/// Either "text", "html", "xhtml", or the MIME type of the content.
pub content_type: Option<String>,
}
Given the text in the RFC, part of me thinks Content should be an enum akin to:
pub enum Content {
Value { ...attributes... },
Source { ...attributes...}
}
Feels like this would help avoid inadvertently going against spec - but if I'm off my rocker please let me know.
Indeed, such enum would prevent someone to author a non-compliant RSS. On the other hand, it won't parse and reject such RSS too. Having a struct allows to consume non-compliant RSS and let a user to make a choice.
Ehhhh, I see your point.
If nothing else, might be useful to add a note to the struct docstring - for someone like me who's only ever looked at the spec once in an eternity, it might be a helpful thing to call out so people don't further author non-compliant feeds.