Should `Content` use an enum to differentiate between `src` and `value`?

[ryanmcgrath]

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.

[andy128k]

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.

[ryanmcgrath]

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.