Subject: PacePersonRef posted

From: Antone Roundy <[email-masked]>
Date: Wed, 30 Jun 2004 09:42:58 -0600

Since I saw no objections to my email of a few days ago, I've posted 
PacePersonRef

http://www.intertwingly.net/wiki/pie/PacePersonRef

Here's the core of it:

* Abstract

This proposal defines a method for creating person constructs at the 
feed level (which do not apply directly to the feed as a whole) and 
then referring to them from the feed level or within entries. Because 
referring to an author can be done compactly, inheritance by entries 
that don't specify an author of the feed:author is removed.

* Rationale

In most feeds, the author is the same for many, if not all, entries, 
leading to repetition of author metadata. This can be avoided by 
specifying the metadata in one place in the feed and referring to it 
from other parts of the feed.

Also, at a conceptual level, while identification of the author and 
contributor(s) is part of an entry, their metadata isn't necessarily 
part of an entry. Thus it may be logically preferable to specify that 
metadata outside of the entry itself.

* Proposal

Insert the following before section 4.5 atom:author of the Atom format 
specification:

4.5 atom:people Element

The "atom:people" element is a container for atom:person elements. It 
MAY contain any number of atom:person elements.

4.5.1 atom:person Element

The "atom:person" element is a Person construct, and MUST follow all 
requirements for Person constructs. Additionally, it MUST have an id 
attribute.

4.5.1.1 id Attribute

The atom:person element's id attribute is a string. It may contain any 
string which does not appear in the id attribute of any other 
atom:person within the feed as it is served at a particular time. It is 
NOT REQUIRED to be unique across feeds, and the id associated with a 
particular Person MAY change. The same id MAY be used for a different 
Person construct each time the feed is served.

Remove "[[explain inheritance]]" from section 4.5.

Replace section 4.13.3 with the following:

4.13.3 "atom:author" Element

The "atom:author" element is a Person construct that indicates the 
primary author of the entry. atom:entry MAY contain one atom:author 
element, but MUST NOT contain more than one. If it does not contain an 
atom:author element, then the author of the entry MUST be considered 
unknown or anonymous. It is not inherited from the feed.

Insert the following under section 3.2 Person Contructs:

3.2.1 "rel" attribute

The "rel" attribute associates a Person construct with an atom:person 
element appearing inside the atom:people element. If a Person constuct 
has a rel attribute, it MUST NOT have any child elements. Instead, 
their values are taken from the atom:person whose id attribute matches 
the rel attribute.

---

From: "Andreas Sewe" <[email-masked]>
Date: Wed, 30 Jun 2004 20:01:24 +0200

> their values are taken from the atom:person whose id attribute matches

Shouldn't this be @ref instead of @rel, which is used in different contexts
too? You suggested this yourself some days ago:

> This looks like a good time to re-raise an idea I mentioned in May in
> reference to copyright information [1].  It got one positive response,
> and no other mention (and no, I didn't create a Pace...if the idea
> doesn't get thoroughly shot down, I will).  Here's a super-simplified
> feed using @id and @ref to minimize data duplication:

Besides that the proposal looks fine to me.

Regards,

Andreas Sewe

---

From: Antone Roundy <[email-masked]>
Date: Wed, 30 Jun 2004 12:06:44 -0600

On Wednesday, June 30, 2004, at 12:01  PM, Andreas Sewe wrote:
> Shouldn't this be @ref instead of @rel

Yeah, I noticed that just after sending the email out and have fixed it 
on the wiki.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 30 Jun 2004 22:53:38 +0200

> Since I saw no objections to my email of a few days ago, I've posted  

Nice. Could you give at least one example of how it might look like (I  
think you wrote one in an e-mail not long ago)?

> feed level (which do not apply directly to the feed as a whole) and then  
> referring to them from the feed level or within entries.

Would it not be possible to have a «full» atom:author element inside  
atom:entry? E.g., should it only be possible to define authors at the feed  
level, and only refer to these at the entry level? And what do you mean by  
«referring to them from the feed»? Aren't the authors defined at the feed  
level? Would it then make sense to refer to these definitions also at the  
feed level?

> Because referring to an author can be done compactly, inheritance by
> entries that don't specify an author of the feed:author is removed.

+1.

> from other parts of the feed.

Would it be possible to extend this Pace to also include external  
referring authors, which could be, e.g. a FOAF file? The file could of  
course also be a centrally stored XML file with an <author> document in  
it, but when referring externally, I guess it makes more sense to refer to  
something more useful, like FOAF.

> MAY contain any number of atom:person elements.

Do we need this one? Isn't an <author> element in the feed enough, if the  
intent is to not have inheritance and save bytes? Then, if an entry shares  
author with the feed, entry/author can refer to feed/author, if an entry  
doesn't have an author, no atom:author element is provided, and if the  
entry has another author than the feed, it just provides its own  
atom:author element.

Shouldn't that cover most everything?

> requirements for Person constructs. Additionally, it MUST have an id  

I don't see the need for another person construct element, but I  
understand where you're going with this, now. You're thinking of having an  
atom:people element in atom:feed which has several child nodes of  
atom:person, which again will be referred to by atom:author and possibly  
atom:contributor elements inside the entries. Right?

Sounds like a decent idea, but I think it's a tad too complicated. Keeping  
the current model with atom:author elements, I think it's enough to add  
one (@ref) or three (@ref, @href and @type) attributes to the Person  
Construct.

> The atom:person element's id attribute is a string.

Can't it just be an xml:id?

> It may contain any string

«May» should not be used in any other context than «MAY» as per RFC 2119.  
«Might» is better.

> which does not appear in the id attribute of any other atom:person
> within the feed as it is served at a particular time.

If we use xml:id, the value has to be unique within the document, no  
matter what element it occurs on. xml:id might show up on other elements  
in the future, and there's really no reason why an ID value shouldn't be  
locally unique, reagardless of what the ID is for.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Wed, 30 Jun 2004 17:27:14 -0600

> Could you give at least one example of how it might look like (I think 
> you wrote one in an e-mail not long ago)?
Okay, here's a feed with things not relevant to this proposal omitted 
(I'll add this to the Pace):

<feed>
	<!-- Complete Person constructs can appear outside of <people> -- when 
they do, they apply to their parent element -->
	<author>
		<name>Arthur McFeed</name>
	</author>

	<people>
		<person id="qwerty">
			<name>John Doe</name>
		</person>
		<person id="asdf">
			<name>Jane Smith</name>
			<url>http://www.janesmith.com/</url>
		</person>
	</people>
	
	<!-- John Doe is a contributor to the feed -->
	<contributor ref="qwerty" />

	<entry>
		<!-- John Doe is the author of this entry -->
		<author ref="qwerty" />
	</entry>

	<entry>
		<author>
			<name>Sylvester McMonkey McBean</name>
		</author>
		<!-- Jane Smith is a contributor to this entry -->
		<contributor ref="asdf" />
	</entry>

	<entry>
		<!-- This entry contains no author or contributor -- it does NOT 
inherit them from the feed ->
	</entry>
</feed>

*  I suppose since the "ref'able" Person constructs are <person> 
elements rather than <author> or <contributor>, <people> isn't strictly 
needed--I won't cry if people suggest getting rid of the container--but 
if this model is used for other things than people, we may want to have 
SOME kind of container for where we define things to be referred to 
from elsewhere.

>> then referring to them from the feed level or within entries.
>
> atom:entry? E.g., should it only be possible to define authors at the 
> feed level, and only refer to these at the entry level? And what do 
> you mean by «referring to them from the feed»? Aren't the authors 
> defined at the feed level? Would it then make sense to refer to these 
> definitions also at the feed level?

Hopefully the example above clarifies this.

> course also be a centrally stored XML file with an <author> document 
> in it, but when referring externally, I guess it makes more sense to 
> refer to something more useful, like FOAF.

I think that's a subject for a different proposal.

> understand where you're going with this, now. You're thinking of 
> having an atom:people element in atom:feed which has several child 
> nodes of atom:person, which again will be referred to by atom:author 
> and possibly atom:contributor elements inside the entries. Right?

Exactly.  The reason for having this be <person> rather than <author> 
or <contributor> is that the same person could be the author of one 
entry and a contributor to another, and perhaps even fill one of those 
roles for the feed.  <person> defines a person, but doesn't, by itself, 
say anything about that person's role.  An <author> or <contributor> 
referring to that <person> specifies what that person's role is.

> Sounds like a decent idea, but I think it's a tad too complicated. 
> Keeping the current model with atom:author elements, I think it's 
> enough to add one (@ref)

I thought about doing it that way, but it felt cleaner to have a single 
set of <person> elements to refer to than to have to match a @ref to an 
@id that could be in an <author>, a <contributor> (perhaps a <person>) 
or whatever other Person constructs we may later add (editor...).  I 
also considered (but not for very long) allowing a Person construct 
(not <person> element) from one entry to @ref one from another entry, 
but that seemed like it would get way too convoluted.  This just seemed 
like the cleanest way to define a bunch of re-usable Person constructs.

> Can't it just be an xml:id?
...
> matter what element it occurs on. xml:id might show up on other 
> elements in the future, and there's really no reason why an ID value 
> shouldn't be locally unique, reagardless of what the ID is for.

I hadn't thought about that--that might be a good way to go.

> «May» should not be used in any other context than «MAY» as per RFC 
> 2119. «Might» is better.

Or perhaps "can".

I guess we should be holding off on too much discussion of this till it 
gets to the Proceed list.

Antone

---

From: Eric Scheid <[email-masked]>
Date: Thu, 01 Jul 2004 13:37:12 +1000

> something more useful, like FOAF.

change the data type of @ref to URI, and we can refer to defined authors
like this:

    <author ref="#someauthorinthisfeedinstance" />
    <!-- note the simple extra bit of "#" -->

    <author ref="http://example.org/foo.foaf#fred"
        type="application/xml+foaf" />

I'm in two minds for this: it provides an extensibility path, but it opens
awkward questions about what happens if the referenced element is not a
<person> construct

> 3.2.1 "ref" attribute

we need some extra language to explain that any given <person> construct can
have @id or @ref but NOT both.

e.