Bob Wyman wrote:
Aristotle Pagaltzis wrote:
That issue is inheritance.
Let me give an example of problematic inheritance...
Some have suggested that there be a "License" that you can associate
with Atom feeds and entries. However, scoping becomes very important in this
case because of some peculiarities of the legal system.
One can copyright an individual thing and one can copyright a
collection of things. A claim of copyright in a collection is not, however,
necessarily a claim of copyright over the elements of the collection.
Similarly, a claim of copyright over an element of the collection doesn't
reduce any claim of copyright in the collection itself.
If we assume inheritance from feed elements, then without further
specification, it isn't possible to claim copyright in the collection that
is the feed without claiming copyright in its individual parts. What you'd
have to do is create two distinct types of claim (one for collection and one
for item. That's messy.)
I'm sure that copyright and licenses aren't the only problematic
contexts here.
bob wyman
From the format text: "If an atom:entry element does not contain
atom:author elements, then the atom:author elements of the contained
atom:source element are considered to apply. In an Atom Feed Document,
the atom:author elements of the containing atom:feed element are
considered to apply to the entry if there are no atom:author elements in
the locations described above."
This really does not describe an inheritance model*. This describes a
scoping model. If an entry does not contain an author, the author on
the feed is said to apply. If the entry does happen to have an author,
it doesn't matter if the feed also has an author, it is the author
element on the entry that applies to the entry. Same thing with the
license extension (for example). If both the feed and entry contain
license links, it is the license link on the entry that is relevant to
the entry. If the entry does not contain a license, it looks to the
feed level. Placing a license on the feed level does not change the
license of the entry if the entry already has a license.
There is another example of this kind of scoping that we're all
intimately familiar with:
<x:a xmlns:x="urn:namespace-1" xmlns="urn:namespace-2">
<x:b xmlns:x="urn:namespace-3">
<c />
</x:b>
</x:a>
From Section 5.1 of Namespaces in XML: "The namespace declaration is
considered to apply to the element where it is specified and to all
elements within the content of that element, unless overridden by
another namespace declaration"
(http://www.w3.org/TR/REC-xml-names/#scoping)
To directly address Bob's point that "it isn't possible to claim
copyright in the collection that is the feed without claiming copyright
in its individual parts" -- it IS possible if we are looking at this in
terms of relevant scope as opposed to inherited properties.
Note to self: I need to fix the license spec to address this. Currently
the spec limits the license relevance to entries without providing a
mechanism for attaching a license to the feed itself.
Second note to self: After thinking about this a bit more, I would also
need a way of specifying a null license (e.g. the lack of a license).
For instance, what if an entry that does not contain a license is
aggregated into a feed that has a license. The original lack-of-license
still applies to that entry regardless of what is specified on the feed
level. Golly Bob, you're right, this is rather messy ain't it. Hmm...
- James
* I've called this inheritance in the past but now I do believe that I
was mistaken.
