hnews-issues

hNews issues

These are externally raised issues about hNews with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the draft.

IMPORTANT: Please read the hNews FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

Please add new issues to the top of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

Closed Issues

closed issue2009-10-09 raised by Miles De Feyter

Implementation of item-license as it relates to hNews. Reading through the item-license brainstorm it seems to indicate that "item-license" would need to be nested within something with the class of "item". So as this relates to hNews is the suggestion to then have an articles containing div have the three class names of "hnews hentry item"?

At this point, Miles, that is correct (following the licensing-brainstorming concept and guidance). I expect we'll see changes around item-license (it's still just brainstorming), but for the time being, the third class name "item" is needed. --JonathanMalek 16:25, 12 October 2009 (UTC)

Principles as a requirement. Working for a publishing company that owns and operates a large number of different organizations I'd love to incorporate hNews within our publishing system. The hNews requirement for a principles statement could pose a problem though or at least make rolling out hNews a more involved process then it would be otherwise. The issue is, I would now have to go to each product owner and ask then to provide this principles statement to link to. So my concern is now rather then just making a change to the publishing system to support hNews there is this requirement for some supporting content. And due to the nature of the content I can only assume our legal dep. would need to sign off as well, further complicating the adoption of hNews.

+1 I agree that the "principles" property (and probably all other others) should be optional. Tantek 18:29, 29 September 2009 (UTC)

I think it's important to explain why principles is a requirement. hnews is essentially a specialization of hAtom. Its purpose is to distinguish news on the web. Hence the description of source organisation, license and principles. Of these, principles is the only one which consistently distinguishes news on the web from other content (eg. commercial, government). In the future it should be distinguished further by making the principles themselves machine readable (but that is for a later date). Most professional news organisations adhere to a Statement of Principles (e.g. see http://en.wikipedia.org/wiki/Journalism_ethics_and_standards and http://www.journalism.org/resources/ethics_codes). If a site wants to mark up its content but does not want to distinguish it as news, then wouldn't it be easiest to use hAtom? Martin Moore 9:00, 20 September 2009 (UTC)

Having discussed this issue at length outside this brainstorming, we understand some of the concerns of the microformat community regarding 'must', but are still convinced of the criticality of principles to hNews - therefore recommend downgrading from 'must' to 'should'. Martin Moore 14:00, 7 October 2009 (UTC)

Accepted and implemented in 0.1. In keeping with the general direction here, we've changed item-license as well, and would consider adopting the same with source-org as well, if it proves to present the same problems. --JonathanMalek 00:53, 15 October 2009 (UTC)

hCalendar instead of dateline? Would an hCalendar event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted?

Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. Stuart Myles 21:12, 24 August 2009 (UTC)

hCard instead of geo? Is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable?

The reason for geo being highlighted (as an optional field) is to promote at least one location identifier in the story--preferably the most appropriate single location on a map for that particular story. Geo does not have to be related to dateline, but in some examples we've worked on, we show the two collapsed into a single field. --JonathanMalek 23:53, 24 August 2009 (UTC)

For locations referred to in the story, I agree--publishers should be using hCard with the contained geo to markup the locations themselves. One of the concepts I've struggled with is drawing an admittedly arbitrary line between the metadata about a story from the metadata within a story. For the former, we've focused on simplicity and minimalism, primarily as a means to encourage adoption. That has meant preferring rel-tag over in-line entity extraction and markup using compound microformats. For the latter, we feel that the field is open: use whatever microformat fits your purpose, however you can--the more, the better. This lets publishers with minimal technology capabilities at least get started by tweaking a few templates in their CMS, while those more technically inclined aren't limited by the simplicity of the format to a paucity of data. --JonathanMalek 23:53, 24 August 2009 (UTC)

We're working off the licensing-brainstorming discussions for this. Our concern with rel-license was its definition as applying to an entire page, rather than an item within a page. The current discussions around licensing definitely address that. --JonathanMalek 00:02, 25 August 2009 (UTC)