Subject: "Inheritance" is broken

From: Robert Sayre <[email-masked]>
Date: Thu, 11 Nov 2004 22:01:51 -0500

I think we should remove all mentions of inheritance from the spec. The 
two most damaging areas are atom:author and atom:copyright. When those 
elements appear in atom:head, the entries don't "inherit" their values. 
All you can reasonably say about the entry is that it appeared in a feed 
with those elements.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 12 Nov 2004 14:26:39 +1100

> All you can reasonably say about the entry is that it appeared in a feed

or we could try for a more flexible and explicit form of inheritance, such
as:

    <feed>
        <head>
            <author id="foo">...</author>
            ...
        </head>
        <entry>
            <author ref="foo" />
            ...
        </entry>
    </feed>

simple, explicit, allows (in an efficient manner) for the use case of half
the entries being authored by one person and the other half by another.

e.

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 11 Nov 2004 23:09:33 -0500

> the entries being authored by one person and the other half by another.

I'm not saying I agree with this in general, but just 
as a point of interest, I'll point out that SVG 
does this.

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Nov 2004 20:13:28 -0800

On Nov 11, 2004, at 7:01 PM, Robert Sayre wrote:

>
> I think we should remove all mentions of inheritance from the spec. 
> The two most damaging areas are atom:author and atom:copyright. When 
> those elements appear in atom:head, the entries don't "inherit" their 
> values. All you can reasonably say about the entry is that it appeared 
> in a feed with those elements.

Uh, why?   The notion of specifying the author once in the header seems 
sensible and straightforward, particularly in a one-author shop like 
mine. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Fri, 12 Nov 2004 15:17:54 +1100

> as a point of interest, I'll point out that SVG

that's good - not because something else does it, but because we can then
ask this question: has SVG revealed any deep problems with this mechanism?

I'll write up a Pace, but won't bother if there are known problems, deep
intractable problems.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 11 Nov 2004 23:35:41 -0500

Tim Bray wrote:

> mine.

I'm not saying you should have to include author elements in every 
entry. I'm saying that a copyright/author element in an entry doesn't 
'override' the author/copyright of the collective work. There are just 
two attributions.

Put another way, if you have a a feed of ten entries, with one entry 
attributed to someone else, your feed-level authorship still applies to 
all ten entries.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Nov 2004 20:46:19 -0800

On Nov 11, 2004, at 8:35 PM, Robert Sayre wrote:

> Tim Bray wrote:
>
>> Uh, why?   The notion of specifying the author once in the header 
>> seems sensible and straightforward, particularly in a one-author shop 
>> like mine.
>
> attributed to someone else, your feed-level authorship still applies 
> to all ten entries.
>
Once again, why?  It's so easy to explain and understand: if there's an 
<author> in the <head>, then that applies to all the <entry>s which 
don't have their own <author>.  Simple, logical, uncomplicated, 
efficient.  Either you're straining at a gnat or I'm failing to see the 
elephant in the room -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 00:07:24 -0500

Tim Bray wrote:

> It's so easy to explain and understand: if there's an 
> don't have their own <author>.  

Authorship isn't that simple. The <author> in the <head> always applies 
to all the entries. The best we can do is say the stuff in <head> 
applies to the feed and the stuff in <entry> applies to the entry. IMHO, 
getting more specific means defining authorship and copyright.

Robert Sayre

http://www.title17.com/contentStatute/chpt01/sec101.html
--------------------------------------------------------
A  ''collective work'' is a work, such as a periodical issue, anthology, 
or encyclopedia, in which a number of contributions, constituting 
separate and independent works in themselves, are assembled into a 
collective whole.

  A  ''compilation'' is a work formed by the collection and assembling 
of preexisting materials or of data that are selected, coordinated, or 
arranged in such a way that the resulting work as a whole constitutes an 
original work of authorship. The term ''compilation'' includes 
collective works.

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 12 Nov 2004 00:17:58 -0500

Robert Sayre wrote:
> if you have a a feed of ten entries, with one entry attributed
> to someone else, your feed-level authorship still applies to 
> all ten entries.
	This doesn't seem to make sense. There are two scopes for authorship
and copyright in a feed:
	1. The feed as a collection
	2. An entry within the feed/collection
	As far as the law is concerned, copyright and authorship can be
independently claimed for either or both scopes. What you seem to be saying
is that we should simply discard the distinction between these two scopes
and support only the second. What benefit do we get for losing the ability
to express a claim of authorship/copyright which is limited to the
collection and not its entries?
	Objecting to inheritance does not require discarding the distinction
between the two claim scopes. One could say, for instance, that a feed-level
claim applies only to the feed as a collection and that entry-level claims
must be explicitly stated in the entry -- feed-level data is not inherited.
However, I think you'll find that it is so "intuitively obvious" to people
that feed-level claims are inherited by entries that it would be an absolute
waste of time to try to enforce or even encourage that people don't apply
it. Just saying it ain't so doesn't make it not so...

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Nov 2004 21:24:51 -0800

> it. Just saying it ain't so doesn't make it not so...

What Bob said.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Thu, 11 Nov 2004 21:24:20 -0800

On Nov 11, 2004, at 9:07 PM, Robert Sayre wrote:

>> It's so easy to explain and understand: if there's an <author> in the 
>> <head>, then that applies to all the <entry>s which don't have their 
>> own <author>.
>
> Authorship isn't that simple. The <author> in the <head> always 
> applies to all the entries. The best we can do is say the stuff in 
> <head> applies to the feed and the stuff in <entry> applies to the 
> entry. IMHO, getting more specific means defining authorship and 
> copyright.

You're saying that as though it were axiomatic.  I say "on the 
contrary".  The author of 'ongoing' is Tim Bray which should be 
reflected at the <head> level.  On occasion I have had a guest author, 
e.g. http://www.tbray.org/ongoing/When/200x/2004/04/12/FowlerOnIBM  
Normally I would not waste bytes by putting <author> in <entry>, but 
for that <entry> I would, because it has a different author.

Atom has exactly zero chance of capturing the final legal shadings in 
the notion of "authorship" which anyhow vary from country to country 
and Atom is not a U.S. thing.

I think a gnat is being strained at here. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 00:28:38 -0500

>> it. Just saying it ain't so doesn't make it not so...

I am saying that the current spec language is the equivalent of

"The author of the book may be considered the author of all the chapters 
in the book unless someone else is listed as the author of a particular 
chapter."

Yes, intuitively obvious. The spec doesn't need to say this, the 
language just gets us into trouble, and it has absolutely nothing to do 
with interoperation in syndication technology. Out it should go.

And copyright is even worse.

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Fri, 12 Nov 2004 14:34:10 +0900

>> Put another way, if you have a a feed of ten entries, with one entry 
attributed to someone else, your feed-level authorship still applies to all 
ten entries.
 >Once again, why?  It's so easy to explain and understand: if there's an 
<author> in the <head>, then that applies to all the <entry>s which don't 
have their own <author>.  Simple, logical, uncomplicated, efficient. 
Either you're straining at a gnat or I'm failing to see the elephant in the 
room -Tim

Another try in the hope to make it even clearer for Robert:

Inheritance still works. What is special for <author> and <copyright>
in <feed> is that in addition to being inherited like everything else,
they also apply (or Robert things they do or should apply; I haven't
read the spec) to the feed as such.

The feed-level authorship or copyright doesn't apply to 'all ten entries'
in the sense of 'each and every single entry', but only in the sense of
'the specific collection of these ten entries together in this
combination and composition'.

[There is also the issue that authorship and copyright may apply more
or less to such collections; as an example, a third party providing a
feed with "the last ten entries from Tim Bray's blog" cannot claim
much of a copyright because what they do is really trivial; on the
other hand, a careful collection/arrangement of ten entries from
different authors on related topics in a new and artistic way,
together leading to new insights or a big laugh for the reader
can very well claim authorship and copyright.]

If we take the above interpretation, then the case where it may be
easiest to see the difference is the following:
A feed with entries all by one author, but in an original composition
by a second author. (An obvious example might be a feed put together
by the second author to try to show that the first author doesn't
know what he's saying and is constantly contradicting himself.)

In Robert's interpretation, the feed would have the second author,
all the entries would have the first author. In another, purely
and only inheriting, interpretation, which does not attribute
any importance to the feed or sees such attribution as a completely
separate problem, it would be enough to put the first author in
the feed.

So again: The question is not whether things inherit or not, but
whether other than just inheriting, they have their own function
on the feed level. My personal opinion: the later would be fine
with me.

Regards,    Martin.

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 12 Nov 2004 00:55:55 -0500

Robert Sayre wrote:
> it has absolutely nothing to do with interoperation in
> syndication technology. Out it should go.
	It *does* have to do with interoperation in that an important
element of interoperation is that diverse processors have a common
understanding of the meaning of the elements that are being passed around.
In this case, it is inevitable that people will do the "intuitively obvious"
think and assume that inheritance works -- even if we say it doesn't. People
will expect it to continue to work if only because they have become
accustomed to it being the expected case with every flavor of RSS as well as
common practice with Atom 0.3.
	Thus, even if it makes more "sense" to make the rules that you've
proposed, it will only contribute to interoperability problems in the future
as a result of the diversity of implementation and interpretation that will
result. These issues become particularly important when you look at the
problem of generating composite or aggregate feeds. When you extract an
entry from a feed, what is the correct value for author/copyright that
should be inserted with that entry into the destination feed?
	It would make much more sense, I think, to acknowledge that we're
stuck with "inheritance" in at least the ownership fields (author and
copyright) and provide a mechanism to allow people to override the
inheritance when it is inappropriate. This is already assumed to be provided
by having entry-level author/copyright statements trump the feed-level
statements. Perhaps we should complete this system by ensuring that it is
legal to provide null authors and/or copyrights to cover the case where the
feed-level data is known to not apply to the entry yet the "correct" values
are not known. Ie. We could support <author></author>. (The meaning would be
null or "not known" rather than "none".) Or, how does one express "null" in
XML?

		bob wyman

---

From: Martin Duerst <[email-masked]>
Date: Fri, 12 Nov 2004 15:45:12 +0900

>"The author of the book may be considered the author of all the chapters 
in the book unless someone else is listed as the author of a particular chapter."
 >
 >Yes, intuitively obvious. The spec doesn't need to say this,

Why exactly does it not have to say that? The discussion we are
having there seem to indicate that there are different possible
interpretations, so it's better to say which one is the correct one.

 >the language just gets us into trouble,

How exactly? If anything gets us into trouble, it is having
<author> or <copyright> in the first place. There is nothing
wrong in saying:

"If the author of a chapter is the same as the author of the book,
the author of the chapter does not have to be mentioned."
(which is the same as your example sentence above, except worded
from a producer viewpoint rather than a consumer viewpoint).

What we are doing, in other words, is just defining one way to
shorten the format and save bandwidth. It is absolutely unrelated
to interpretation.

 >and it has absolutely nothing to do with interoperation in syndication 
technology. Out it should go.

It does have to do with interoperation in syndication
technology. If some processors assume they can take some shortcuts,
but others don't, we get a mess. In particular, if somebody takes
an entry without explicit <author> out of a feed, and puts it into
another feed, they damn well are required to take the <author> in
the feed and put it into the entry.

 >And copyright is even worse.

Copyright may be worse indeed for interpretation. But we don't
define interpretation. We only say what feeds are equivalent
to what other feeds, for certain forms of feeds.

Regards,    Martin.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 01:59:30 -0500

Martin Duerst wrote:

> In particular, if somebody takes

Except that synthetic feed producers don't seem to want that. They want 
to put atom:head in atom:entry.

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Fri, 12 Nov 2004 17:38:16 +0900

Right. When I said 'put <author> into the entry' above, I didn't
care whether that would be in <head> in <entry> or directly in
<entry>.

Regards,    Martin.

---

From: Danny Ayers <[email-masked]>
Date: Fri, 12 Nov 2004 12:37:18 +0100

I think there is clearly need for clarification in the spec if there's
so much room for (mis)interpretation. I am in favour of inheritance,
but it's not altogether straightforward.

Say you have a feed F containing entries a, b, c:

F = [a, b, c]

and authorship is expressed as auth(a, x)

The way I read inheritance as it stands was:

auth(F, x) => auth(a, x), auth(b, x), auth(c, x)

But the idea of authorship of the collection might screw this up, only allowing:

auth(F, x) => auth([a, b, c], x)

or are you actually asserting both? i.e.

auth(F, x) => auth([a, b, c], x), auth(a, x), auth(b, x), auth(c, x)

Things get even worse when individual entries have authorship too -
which of the following is it? :

auth(F, x), auth(c, y)
=>
auth(a, x), auth(b, x), auth(c, x)

or

auth(F, x), auth(c, y)
=>
auth(a, x), auth(b, x), auth(c, x), auth(c, y)

or

auth(F, x), auth(c, y)
=>
auth([a, b, c], x), auth(c, y)

or the combination of the last of these with each of the first two..?

I think if we are to make use of inheritance then we need to
differentiate clearly between what is meant by authorship (or
whatever) of the feed as an entity in its own right and authorship of
the feed as a series of entries, i.e. a, b, c... != [a, b, c...].

I think inheritance would be worthwhile as I think it would make it
more likely that attribution data would be available to consumers.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 12 Nov 2004 12:36:40 +0000

Tim Bray wrote:
> efficient. 

I wonder if it's simple. The fact that it has to be explained 
repeatedly to one of the editors indicates a problem *. I'm not sure 
it's simple for multi-author scenarios or composite feeds. It'll 
work for my blog, but I don't know if it's work for pubsub.

Specifically: if the inheritence rules we've outlined can result in 
false positives (ie an incorrect authoring attribution), it needs to 
rectified/clarified. Danny's written out the implications, perhaps 
he can tell us one way or another.

Fwiw, damaging data like this is bad form and standardizing it is 
unlikely to get my consensus - I don't much care if it's legacy or 
de facto in current formats (as Martin has pointed out). Even if 
it's not harmful, there's absolutely a need to firm up the text.

cheers
Bill

* One of my pet observations from my relatively short time in this 
industry is that the consequences of implicit of such inheritence 
and scoping mechanisms consistently trips people up - I've never 
seen simple inheritence.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 12 Nov 2004 10:36:22 -0500

Bill de hÓra wrote:

> 
> I wonder if it's simple. The fact that it has to be explained repeatedly 
> to one of the editors indicates a problem *. 

The problem may be the editor :)
Most people seem to disagree with me.

> unlikely to get my consensus - I don't much care if it's legacy or de 
> facto in current formats (as Martin has pointed out). Even if it's not 
> harmful, there's absolutely a need to firm up the text.
> 

If we go with this, I want to get rid of the "applies to" language. We 
should make it as clear as possible that the elements have been elided, 
and we're just talking about document structure.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Fri, 12 Nov 2004 08:45:42 -0700

> I'll write up a Pace, but won't bother if there are known problems, 
Anyone considering such a solution might refer to PacePersonRef[1], 
although it's in the "Closed" list.  It did what's described in this 
thread, and did away with inheritance.  Reasons for closing it:

http://www.imc.org/atom-syntax/mail-archive/msg09290.html
PacePersonRef contains, among its "Key Questions": "2. Do we want 
entries to inherit the author from the feed if they don't specify one?" 
This seems simple and straightforward and easy to understand, thus my 
answer would be "yes', so I guess I'm -1 on this proposal.

http://www.imc.org/atom-syntax/mail-archive/msg09490.html
PacePersonRef got one -1 from me, and nobody, including its author, 
objected. Absent pushback, rejected.

It's author (yours truly) did not object because hardly anyone had 
commented on the proposal, and I read silence as ambivalence, and thus 
felt uninclined to fight for it.  Perhaps the proposal should be 
revisited, with revisions if necessary.

Another option would be to create a generalized mechanism for 
referencing data whereby, for example, any element (and it's child 
content and elements) with an @id can be @ref'ed, possibly with 
limitations as to where the @id'ed element can appear.

[1] http://www.intertwingly.net/wiki/pie/PacePersonRef

---

From: Graham <[email-masked]>
Date: Fri, 12 Nov 2004 16:08:44 +0000

On 12 Nov 2004, at 3:45 pm, Antone Roundy wrote:

> thread, and did away with inheritance.

-1 on reopening PacePersonRef. It's boring and unnecessary - a complex 
solution to a non-problem.

I think inheritance as it stands makes perfect sense btw.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 12 Nov 2004 11:06:33 -0500

Bill de hÓra wrote:
> I'm not sure it's simple for multi-author scenarios or composite
> feeds. It'll work for my blog, but I don't know if it's work
> for pubsub.
	As currently specified, it doesn't work for PubSub. The problem is
that any author/copyright statements that we make at feed-level for our
composite feeds end up getting inherited by any entry that we publish that
doesn't have its own author/copyright information. This is one of the
reasons that I have been arguing for PaceHeadInEntry. I want to make it
possible to clearly establish the scope for inheritance.
	In a composite feed, no feed-level data should be inherited by
entries. However, I think it is overly onerous requirement to say the same
for non-composite feeds. Thus, we need a way to block the inheritance --
hopefully without introducing to many mechanisms that are specific to
composite feeds. Personally, I think that PaceHeadInEntry is probably the
best compromise here. It allows explicit statement of inheritable data while
requiring minimal modification to the definition of an entry. To properly
and completely cover the cases here, I think we should also consider
allowing "null" values for inheritable fields so that non-composite feed
developers can block inheritance. Alternatively, we should have a rule that
says: If you need to block inheritance in a non-composite field, simply put
a head in the entry that declares the correct values. (An empty <head/>
might also be useful as a block of all inheritance.)

		bob wyman

---

From: Lance Lavandowska <[email-masked]>
Date: Fri, 12 Nov 2004 10:35:49 -0600

> thread, and did away with inheritance.  Reasons for closing it:
<snip>

> [1] http://www.intertwingly.net/wiki/pie/PacePersonRef

I think reopening PacePersonRef would be best, as it seems to address
most of the issues I've seen in this discussion.  The point of
contention (evidenced by the name of this thread) is inheritence, with
three suggestions:
1) no inheritance: feed:author is just for the feed.
2) yes inheritance: the author of the feed is also the author of each
entry unless specified otherwise.
3) yes inheritance, with a NULL option: as #2 but provide a mechanism
by which an entry can be specified to have an 'unknown' author.

Tim Bray's objection was solely based on inheritance.  If we can nail
that down we should be able to accept this proposal.

> limitations as to where the @id'ed element can appear.

In this regard PacePersonRef is similar to what I suggested
(informally)[2].  Categories got wrapped in hierarchy discussions and
I didn't see any consensus formed.  If you threaten me with "write a
Pace" it'll largly be copy-pasted from PacePersonRef.

I'll admit that I am just barely XML-literate, but I thought all XML
operated on this principle (that you could refer to another node by
its @id via a @ref).

Lance Lavandowska

[2] http://www.imc.org/atom-syntax/mail-archive/msg11331.html

---

From: Walter Underwood <[email-masked]>
Date: Fri, 12 Nov 2004 09:41:00 -0800

> null or "not known" rather than "none".) Or, how does one express "null" in

I like this, though I'd prefer something really clear, like

<author notspecified="true"/>.
I'd prefer a different term than "inheritance", because that brings up
classes and type systems for a lot of people. How about "defaulting",
"elision", "use value from the feed", or "cascading values". Hmm, kinda
like that last one.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Danny Ayers <[email-masked]>
Date: Fri, 12 Nov 2004 19:19:56 +0100

On Fri, 12 Nov 2004 09:41:00 -0800, Walter Underwood <[email-masked]> wrote:

Details aside -

> I'd prefer a different term than "inheritance",

+1

-- 

http://dannyayers.com