Split home_page_url into two separate fields

[jbafford]

home_page_url is described as being the url of the resource the feed describes, which may or may not be a "home" page.

I think this should be broken into two different (and optional) fields for clarity of purpose:

• site_url should reference the actual home page for the site the feed is for
• resource_url should reference the url of the resource the feed describes (the current stated purpose of home_page_url).

The need to have a separate site_url and resource_url comes when the home_page_url does not point at a home page, or should not exist because (for whatever reason) there is no explicit resource the feed describes.

For example, if home_page_url == https://subdomain.example.org/someplace/, it might be desirable to instead say

• site_url = https://example.org/
• resource_url = https://subdomain.example.org/someplace/

Alternatively, a feed may exist for which there is no url that adequately describes it. For example, one can imagine a (not necessarily web-based) library that generates a jsonfeed based on some arbitrary criteria provided by its user. The library may wish to specify a site_url to advertise itself, but have no resource_url because there is none.

Backwards Compatibility

Simply changing home_page_url to resource_url would represent a breaking change. To follow the spec's stated forward compatibility goals of making version 1 feed valid version 2 feeds, we could declare that new parsers should interpret the two fields as synonyms of each other: if resource_url is provided, then that value will be used; else if home_page_url is present, then that value will be interpreted as the resource_url. home_page_url would be marked as deprecated in the spec. If both are present, home_page_url is ignored.

Alternatively, we can keep home_page_url named as-is, and note its apparent mislabeling as a historical oddity in the spec.

Other issues

• This issue would obviate #28.
• Support for relative urls (#8) is also related.

[dissolve]

I would not worry too much about backward compatibility so early in a format's infancy.

My first opinion was that 'home_page_url' was not a great name though, as it does describe the location of the feed, not a "home page" which I don't really think makes a lot of sense.

my suggestion would be to go with just 'url' and 'jsonfeed_url' most descriptive for the actual jsonfeed location, and url to keep simple and hopefully start to look more like existing specs that it would be good to converge with.

[dissolve]

or to put it a bit shorter, i don't think you need a third url, for a 'home_page' which i think makes more sense as just either look for the url of the feed, look for the url of the jsonfeed equivalent, or look for the url of the author.