At 6:29 PM -0400 5/7/05, Robin Cover wrote:
The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'.
As before, -1. In fact, I would prefer to remove atom:copyright from the core before we make a post-last-call move to substitute a less-defined element such as atom:rights.
Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless.
Fully disagree. Later, you suggested that the renamed element would have a URI that pointed to the rights asserted by the author. That has a *lot* of effects, including the need for someone to resolve that URI before republishing the content in another feed, and storing the resolution of that URI with a copy of the contents (so that that author can't change the contents and then come after you). That is far from harmless.
Using the element name 'atom:rights', as argued below, could enhance interoperability
Sorry, I didn't see anything in the rest of the post that showed how this could increase interop. Please be specific here. To me, you can't get much more interoperable than an unstructured, human-readable, free-text blob such as atom:copyright.
and avoid some unforeseen and unintended
legal implications that may emerge from use of the term
("copyright").
Legal FUD doesn't help here. The current atom:copyright entry has no properties different than allowing someone to type in whatever human-readable copyright notice they want in an HTML document. If someone is comfortable with asserting a copyright, they can; if they're not, they don't have to.
Something non-legal, like 'rightsDescription="URI"'.
Please explain how "rightsDescription" is "non-legal" while "copyright" is legal. Seriously, I don't see how they can be differentiated. If you claim particular rights, that's a legal assertion of the same strength as claiming a copyright.
I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread "abuse" of the 'atom:copyright' element. Surely, "multiple (incompatible) ad hoc solutions will be invented" ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless.
This goes back to the question of what goes into the core and what is done as an extension. I would strongly support the latter because, as you posit, people will disagree on how they should be able to assert rights. Coming up with a single extension structure that will keep everyone happy will take a lot of wrangling, but the effort would probably be worth it.
--Paul Hoffman, Director --Internet Mail Consortium
