James M Snell wrote:
>
> 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.
"scope" v "inheritance": call what you like, it's still undefined.
1. We didn't do that, I imagine because it was 'simpler' to say nothing
than introduce formalism. The only person that has tried to formally
define the relationship is Henry afaik. Unless we have defined clearly
the semantics of the relationship between a feed and a entry*, we're
hosed if we start trying to figure out the logical implications of
domain and range of metadata - whatever we conclude, unless it gets
baked into a spec as a patch, somebody with running code will be sure to
conclude otherwise. Coincidentally I posted a rant about this kind of
specification on xml-dev the other day mentioning feed/entry.
2. It's easy to be tricked by the document structure into thinking there
is some form of natural scoping mechanism. If Atom looked like this
atom:feed
atom:feed-metadata-container
atom:entries-container
atom:entry
or
atom:feed
atom:entries-container
atom:[EMAIL PROTECTED]'feed-metadata'
atom:entry
We probably wouldn't be having this discussion.
> 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...
This is not new ground for the WG. We've been through it and my
understanding is that feed level metadata does not inherit/cascade/scope
over entries. I seem to recall thinking that atom:author percolating
down from the feed is essentially broken, but the consensus was it
should do that. It's an exception, not a precedent.
As we have no processing model for this, my answer to Paul's question is
that feed level extensions do not inherit/cascade/scope over entry level
ones, irrespective of whether they're foreign or not, and that the best
way to think about atom:author is as a frozen accident.
[I hope the folks working on the APP are paying attention.]
cheers
Bill
* Tangentially touched upon here:
http://www.dehora.net/journal/2004/06/atomrss_relating_entries_and_feeds.html.
