Subject: multiple atom:author elements?

From: Eric Scheid <[email-masked]>
Date: Fri, 20 May 2005 13:41:49 +1000

I see this as a problem...

> 4.1.2 The "atom:entry" Element
>
> * atom:entry elements MUST contain exactly one atom:author element, unless
>   the atom:entry contains an atom:source element which contains an atom:author
>   element, or, in an Atom Feed Document, the atom:feed element contains an
>   atom:author element itself.
> * atom:entry elements MUST NOT contain more than one atom:author element.

Science Journals are just one example of feeds which require being able to
specify multiple authors per entry. I have Library clients who want to make
their indexing efforts available in XML form - currently I can recommend RSS
1.0, but I would like to be able to recommend Atom 1.0 when it becomes
available. With a one-author-per-article restriction this would be
impossible.

Shall I write a Pace?

e.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 19 May 2005 22:10:44 -0600

> available. With a one-author-per-article restriction this would be

If we do allow multiple authors, we might want to put a warning in that 
consuming applications MAY ignore some of them if more than one is 
supplied.  As long as we do that, and perhaps even if not, I'd be in 
favor of allowing more than one.

---

From: Dan Brickley <[email-masked]>
Date: Fri, 20 May 2005 00:41:13 -0400

* Antone Roundy <[email-masked]> [2005-05-19 22:10-0600]
> favor of allowing more than one.

Consuming apps can do whatever they like; that's a freedom this spec 
can't offer, or restrict. It's just a document. Atom's job here imho 
is to be clear about what the document means. It's much easier to 
standardise on a type of document, than a type of software application 
for consuming those documents.

(I support allowing multiple authors, fwiw)

Dan

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 May 2005 15:01:15 +1000

> favor of allowing more than one.

I'm happy with that - the market will sort out what is an acceptable level
of support.

I really don't want to see this in an Atom feed:

    <author><name>Raggett, D, Hors, A, and I Jacobs</name></author>

(perfectly acceptable for display, but not for data)

e.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 May 2005 08:57:08 +0200

> (perfectly acceptable for display, but not for data)

+1

As a general rule: trying to forbid reasonable things usually causes 
producers to look for workarounds that seem to "work" in most clients. 
This is a very nice example where insisting on a single entry will 
probably do more harm than allowing multiple entries.

Julian

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 20 May 2005 13:05:01 +0300

> >>favor of allowing more than one.

+1 from me as well, from the Wiki perspective.  If you want to do
things like "daily feeds", you're going to get more than one author.

/Janne

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 07:14:40 -0400

> available. With a one-author-per-article restriction this would be

-1. This is an edge case, and one that's not covered by RSS 1.0, btw.
Dublin Core elements make perfect sense in an Atom feed.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 20 May 2005 12:22:30 +0100

> available. With a one-author-per-article restriction this would be

Legal documents and legislation are others. Good catch Eric. I'll 
support this.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 20 May 2005 12:25:30 +0100

> Dublin Core elements make perfect sense in an Atom feed.

DC elements makes sense, but we have consistently chosen not to use 
them. So, if consensus is that it's not an edge case, then that would 
argue in favour of designing something into the format.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Fri, 20 May 2005 12:40:16 +0100

On 20 May 2005, at 4:41 am, Eric Scheid wrote:

> I have Library clients who want to make their indexing efforts  
> available in XML form - currently I can recommend RSS

The one author restriction isn't really necessary. My only problem is  
with our "order is not significant" rule since there's a strong  
likelihood that authors will be displayed in the the order they  
appear in the XML, and that publishers will expect it.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 07:51:19 -0400

>     <author><name>Raggett, D, Hors, A, and I Jacobs</name></author>

*gasp. multiple nouns inside a single element.

I don't see why that's a problem. For example, you wouldn't be able to
recreate that string from three atom:author elements.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 20 May 2005 13:20:39 +0100

> *gasp. multiple nouns inside a single element.

*gasp. multiple nouns inside a single noun element.

> recreate that string from three atom:author elements.

I see why that's problem. For example you could recreate that string 
from three atom author elements.

cheers
Bill

http://www.ucc.ie/sdata/faq.html#whatis

---

From: Eric Scheid <[email-masked]>
Date: Fri, 20 May 2005 22:33:36 +1000

On 20/5/05 9:51 PM, "Robert Sayre" <[email-masked]> wrote:

> I don't see why that's a problem.

Try then importing those article feeds and producing an a-z index by author.

e.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 09:33:01 -0400

> Legal documents and legislation are others. Good catch Eric. I'll

Those are three terrible use cases. Shall we go through every element
in the format and evaluate their fitness for scientific journals,
legal documents, and legislation?

Robert Sayre

---

From: Ben Lund <[email-masked]>
Date: Fri, 20 May 2005 15:04:09 +0100

Robert Sayre wrote:
>>>specify multiple authors per entry. 
>>

I find it astonishing that you dismiss publishing markets amounting to 
approximately $17 billion annually [1], [2].

Given that this is a need for this (see [3] for an example of how we 
currently choose to deal with this in RSS 1.0), what other rationale is 
there for not having multiple authors?

[1] http://www.epsltd.com/press/pr.28.10.2004.asp
[2] http://www.epsltd.com/press/pr.26.03.2004.asp
[3] http://www.nature.com/nature/current_issue/rss

Ta,

Ben Lund

---

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 10:09:07 -0400

> approximately $17 billion annually [1], [2].

I'm not dismissing them. I'm saying they should use an extension,
which they'll be needing anyway.

> there for not having multiple authors?

We better do something about that from: header in email, too. Just
pick a string. That's all you have to do.

Here's one: the format is done. 

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 10:28:28 -0400

> [3] http://www.nature.com/nature/current_issue/rss

Ooh. Actually, this is quite interesting. What's up with that description field?

Robert Sayre

<item rdf:about="http://dx.doi.org/10.1038/nature03425">
<title>
Three-dimensional deformation caused by the Bam, Iran, earthquake and
the origin of shallow slip deficit
</title>
<link>http://dx.doi.org/10.1038/nature03425</link>
<description>
Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen
</description>
<dc:title>
Three-dimensional deformation caused by the Bam, Iran, earthquake and
the origin of shallow slip deficit
</dc:title>
<dc:creator>Yuri Fialko</dc:creator>
<dc:creator>David Sandwell</dc:creator>
<dc:creator>Mark Simons</dc:creator>
<dc:creator>Paul Rosen</dc:creator>
<dc:identifier>doi:10.1038/nature03425</dc:identifier>
<dc:source>Nature 435,  295 
(2005)
</dc:source>
<prism:publicationName>Nature</prism:publicationName>
<prism:volume>435</prism:volume>
<prism:number>7040</prism:number>
<prism:section>Article</prism:section>
<prism:startingPage>295</prism:startingPage>
<prism:endingPage>299</prism:endingPage>
</item>

---

From: Ben Lund <[email-masked]>
Date: Fri, 20 May 2005 15:37:50 +0100

> Ooh. Actually, this is quite interesting. What's up with that description field?

Yes, it's less than ideal, but there were a couple of reasons for this:

1) It's important to us that the full author string is put in front of 
most readers' eyes very early on, but also that each individual author's 
name is given in a unique field.  Using the description field and 
multiple, separate dc:creator fields [*] seemed like the best compromise

[*] This is actually against the letter of the RSS 1.0 spec

2) There's not much else to go in the description field, as we're not 
putting the abstracts of articles in our feeds (yet...).

Ta,
Ben

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 20 May 2005 15:36:33 +0100

Robert Sayre wrote:
> Those are three terrible use cases. 

Let's suppose there's general agreement here with that opinion. The 
things to ask here nonetheless are

  a) whether drilling multiple author names through a name element 
indicates a design flaw in Atom (overconstraint).

  b) whether multiple authoring is an edge-case; it could well be.

I'm open to persuasion on b); it's not my intent to force this anyone's 
throat. But a) does bother me.

> Shall we go through every element

Unfair :\ Not the least because you're assuming that hasn't been done.

cheers
Bill

---

From: David Powell <[email-masked]>
Date: Fri, 20 May 2005 15:36:31 +0100

> which they'll be needing anyway.

The important thing is that we should make sure that they can use an
extension to do this. The current wording for Person construct might
suggest that a Person construct is a singular entity.

Perhaps the definition of atom:name should be tweaked to make it a
label for the Person construct.  atom:name sounds too much like a
singular name of a person or company.

Simple Extension Elements could be a useful way of adding additional
information about multiple author. Multiple dc:creator or foaf:name
elements could be used directly in the person construct to document
the separate names, leaving atom:name as a printable label, eg:

<atom:author>
  <atom:name>Mark Nottingham and Robert Sayre</atom:name>
  <dc:creator>Mark Nottingham</dc:creator>
  <dc:creator>Robert Sayre</dc:creator>
</atom:author>

There is a limitation though that this approach couldn't be used to
include the email addresses or organisations of multiple authors
because there wouldn't be an easy way to associate these properties
with the correct person.

A risk of allowing multiple atom:author elements is that it might
break the feed/entry inheritance thing:  does atom:entry/atom:author
override or merge with atom:feed/atom:author?  I suppose a FOAF block
could be included as a Structured Extension Element.

> pick a string. That's all you have to do.

Bad example :)

from            =       "From:" mailbox-list CRLF

-- 
Dave

---

From: James Aylett <[email-masked]>
Date: Fri, 20 May 2005 15:45:21 +0100

> pick a string. That's all you have to do.

The from header in RFC 2822 is a structured header that supports
multiple email addresses, so this isn't a terribly good example. (If I
understand your intention.)

Personally I'm in favour of having multiple authors, but I'm +0.5 on
ending this discussion any way possible. Although it does actually
affect me, there are workarounds which I'll tolerate (although it
precludes Atom as an archival format in some cases, there are
workarounds in these cases as well if necessary).

So I'm actually +0, I guess.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 10:49:16 -0400

> singular name of a person or company.

Hmmm. That's true. There also seems to be a stigma attached to
atom:contributor.
 
> because there wouldn't be an easy way to associate these properties

Right now, the spec reads as if there is one primary person, and then
a bunch of contributor minions. The example also makes it look that
way. Maybe we could adjust it to make atom:author a 'primary field'
and then atom:contributor could break each entity. So, Ben's example
would have 1 atom author field and four atom:contributors.

> from            =       "From:" mailbox-list CRLF

Doh! RFC2822 can be so harsh.

Robert Sayre

---

From: Ben Lund <[email-masked]>
Date: Fri, 20 May 2005 16:02:21 +0100

> would have 1 atom author field and four atom:contributors.

You mean:
--------
<atom:author>
   <atom:name>Yuri Fialko, David Sandwell, Mark Simons &amp; Paul 
Rosen</atom:name>
   <atom:contributor>Yuri Fialko</atom:contributor>
   <atom:contributor>David Sandwell</atom:contributor>
   <atom:contributor>Mark Simons</atom:contributor>
   <atom:contributor>Paul Rosen</atom:contributor>
</atom:author>
--------
?

I like that structure.

Ta,
Ben

---

From: Dan Brickley <[email-masked]>
Date: Fri, 20 May 2005 11:04:42 -0400

* Ben Lund <[email-masked]> [2005-05-20 15:04+0100]
 
+1

I guess those who chose to use Atom despite this constraint will just 
use extension namespaces instead of Atom's built-in 'author' construct
for feeds that describe multiple-author documents. If Atom is basically 
optimised for blogging, then this kind of design is only to be expected.
If Atom feeds are for all kinds of documents, the constraint seems
short-sighted.

Dan

> Publishers Limited or its agents by means of e-mail communication. 
> Macmillan Publishers Limited Registered in England and Wales with 
> registered number 785998 Registered Office Brunel Road, Houndmills, 
> Basingstoke RG21 6XS

---

From: Ben Lund <[email-masked]>
Date: Fri, 20 May 2005 16:10:44 +0100

Robert Sayre wrote:
> I meant
> <entry>
>   <atom:uri>http://research.example.org/dept/</atom:uri>
>  </atom:author>
> 
>   <atom:contributor> 
>     <atom:name>Yuri Fialko</atom:name>
>     <atom:uri>http://research.example.org/dept/fialko/</atom:uri>
>   </atom:contributor>
>     
>   <atom:contributor> 
>     <atom:name>David Sandwell</atom:name>
>     <atom:uri>http://research.example.org/dept/sandwell/</atom:uri>
>   </atom:contributor>
>   <atom:contributor> 
>     <atom:name>Mark Simons</atom:name>
>     <atom:uri>http://research.example.org/dept/simons/</atom:uri>
>   </atom:contributor>
>   <atom:contributor> 
>     <atom:name>Paul Rosen</atom:name>
>     <atom:uri>http://research.example.org/dept/rosen/</atom:uri>
>   </atom:contributor>
> 
> ...
> </entry>
> 

Okay, cool.  I like that too...

Ta,
Ben

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 11:08:00 -0400

I meant

<entry>

<atom:author>

  <atom:contributor> 
    
  <atom:contributor> 

...
</entry>

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 08:53:08 -0400

> from three atom author elements.

Here's what's required to produce that string

http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 20 May 2005 16:17:06 +0100

On 20 May 2005, at 4:12 pm, Robert Sayre wrote:

> Well, the two examples we've been shown want to control presentation
> when multiple authors are grouped.
>
> "Raggett, D, Hors, A, and I Jacobs"
> "Yuri Fialko, David Sandwell, Mark Simons &amp; Paul Rosen"

The logical answer would then be a new element for that label when  
multiple atom:authors are present.

Does anyone remember the reason we have atom:contributor? I say drop it.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 01:35:03 +1000

> would have 1 atom author field and four atom:contributors.

I'm liking this idea. The main thing we'd want to fish out of <atom:author>
(sic) would be <atom:name> ... which would be renamed to be <atom:byline>.
All the nitty gritty details on each person involved would then be described
in multiple <atom:contributor/>s.

We'd still need to cater to the use case of the Esteemed Author And His
Lowly Contributor Minions though ... and thus (assuming the above model)
introduce a new contributor attribute for role of contribution (such as
"author", "contributor", "editor", "photographer").

An example:

    <entry>
        <title>this is the title</title>
        <byline>Foo, Bar, and Fum</byline>
        <contributor role="author">
            <name>Barnable Foo</name>
            <.../>
        </contributor>
        <contributor role="author">
            <name>Sir Ignacious Bar, Esq.</name>
            <.../>
        </contributor>
        <contributor role="author">
            <name>Fred Fum</name>
            <.../>
        </contributor>
        <contributor role="photographer">
            <name>Some guy</name>
            <!-- yes, this contributor got no props in the byline -->
            <.../>
        </contributor>
        <content/>
    </entry>

Or ... and this is a crazy idea ... we could instead support inserting
<category> inside the <contributor> element, thus even allowing us to link
to a controlled schema, just in case people have lots of funky roles.

        <contributor>
            <category term="Author"/>
            <name>Barnable Foo</name>
            <.../>
        </contributor>

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 01:36:51 +1000

> could be included as a Structured Extension Element.

That feed/entry inheritance thing is going to bite us again, I'm sure.

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 03:19:22 +1000

>           <name>Barnable Foo</name>

actually, I'm liking this more and more, because...

       <contributor>
           <name>Barnable Foo</name>
           <category term="Author"/>
           <category term="Photographer"/>
           <category term="Cat Herder"/>
           <.../>
       </contributor>

(Just in case it's not obvious, my use of the <category> elements above
describe the nature of *contribution* of that person to that entry, and not
a sense of identity for that person.)

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 May 2005 19:41:35 +0200

+1

Very elegant.

As for the inheritance problem this does bring up: the current
spec implicitly defines that no inheritance from the feed takes
place when an entry has its own author element, because there is
only ever one author for any entry, so if it’s the one at the
entry level, it can’t be the one at the feed level. I suggest
that the same approach be chosen in case of this atom:contributor
element, just explicitly. Trying to specify a merging scheme here
would be boiling the ocean.

However, it does pose a problem of default semantics. Do we
define particular categories in the spec? If we don’t, do we
define a default category to be assumed in absence of explicit
category elements in the document? If we do, do we define such
a default?

Lastly, the atom:byline should be optional for those publishers
who wont to control presentation, IMO.

Regards,
-- 
Aristotle

---

From: Danny Ayers <[email-masked]>
Date: Fri, 20 May 2005 19:57:17 +0200

> Does anyone remember the reason we have atom:contributor? I say drop it.

Good question (I can't remember - was feed-level attribution a
consideration?). Looking at it now the primary author/secondary
contributors thing seems open to technical clunkiness and human
discomfort.

If we do allow multiple <author>s, we could ditch <contributor> and at
the same time lessen the likelihood of ugliness like:

I would think the need to assign different statuses to the
author/contributors (and corresponding labelling) will be a rarity
compared to what's covered by allowing multiple authors.

so -

allowing mutiple <author>s: 
+1
removing <contributor>:
+1

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 03:58:11 +1000

On 21/5/05 3:41 AM, "A. Pagaltzis" <[email-masked]> wrote:

> define particular categories in the spec? If we don¹t, do we

The simplest thing that could possibly work is to say that if there is no
<category> element inside the <contributor> then assume a default of
@term="author" with unspecified @scheme and unspecified @label.

Covers 99% of use cases, I should think.

No need to explain what the string "author" means, surely?

e.

---

From: Graham <[email-masked]>
Date: Fri, 20 May 2005 19:17:29 +0100

>            <category term="Cat Herder"/>

Well unless we make category/term machine readable, we might as well  
just have a plain text blob.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 04:18:15 +1000

>> Does anyone remember the reason we have atom:contributor? I say drop it.

this is instructive reading...

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

>   <author><name>Raggett, D, Hors, A, and I Jacobs</name></author>

that string inside <author> is ugly.

that string inside <byline> is desired*

e.

* by some publishers, who by convention have the requirement that
contributors be listed in some proper order.

---

From: Robert Sayre <[email-masked]>
Date: Fri, 20 May 2005 14:20:23 -0400

> compared to what's covered by allowing multiple authors.

Here is a new example for the spec. Is there a use case that's not covered?

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09">
     <title type="text">dive into mark</title>
     <subtitle type="html">
       A &lt;em&gt;lot&lt;/em&gt; of effort
       went into making this effortless
     </subtitle>
     <updated>2005-04-02T12:29:29Z</updated>
     <id>tag:example.org,2003:3</id>
     <link rel="alternate" type="text/html"
      hreflang="en" href="http://example.org/"/>
     <copyright>Copyright (c) 2003, Mark Pilgrim</copyright>
     <generator uri="http://www.example.com/" version="1.0">
       Example Toolkit
     </generator>
     <entry>
       <title>Atom draft-07 snapshot</title>
       <link rel="alternate" type="text/html"
        href="http://example.org/2005/04/02/atom"/>
       <link rel="enclosure" type="audio/mpeg" length="1337"
        href="http://example.org/audio/ph34r_my_podcast.mp3"/>
       <id>tag:example.org,2003:3.2397</id>
       <updated>2005-04-02T12:29:29Z</updated>
       <published>2003-12-13T08:29:29-04:00</published>
       <author>
         <name>Mark Pilgrim, et al.</name>
       </author>
       <contributor>
         <name>Mark Pilgrim</name>
         <uri>http://example.org/</uri>
         <email>[email-masked]</email>
       </contributor>
       <contributor>
         <name>Sam Ruby</name>
       </contributor>
       <contributor>
         <name>Joe Gregorio</name>
       </contributor>
       <content type="xhtml" xml:lang="en"
        xml:base="http://diveintomark.org/">
         <div xmlns="http://www.w3.org/1999/xhtml">
           <p><i>[Update: The Atom draft-07 snapshot is out.]</i></p>
         </div>
       </content>
     </entry>
   </feed>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 May 2005 20:33:47 +0200

* Graham <[email-masked]> [2005-05-20 20:30]:
> Well unless we make category/term machine readable, we might as
> well just have a plain text blob.

But we already did that. There’s an option @scheme attribute for
atom:category. That’s part of the elegance of this approach.

Regards,
-- 
Aristotle

---

From: Eric Scheid <[email-masked]>
Date: Sat, 21 May 2005 04:37:44 +1000

> just have a plain text blob.

it is machine readable:

<category   
    scheme="http://www.loc.gov/marc/sourcecode/relator/relatorlist.html
    term="aut"
    label="Author"
/>

they also define many more terms...

    Calligrapher [cll]
    Cartographer [ctg]
    Collaborator [clb]
    Photographer [pht]
    Author in quotations or text extracts [aqt]
    Censor [cns] 
    Dubious author [dub]

:-)

e.

---

From: Walter Underwood <[email-masked]>
Date: Fri, 20 May 2005 11:49:04 -0700

> legal documents, and legislation?

Here is a list of 341 scientific journals with RSS feeds. Soem of
these use a single author element with multiple authors crammed in,
some use multiple author elements. The author elements have other
problems, like "Binks, J. J." vs. "Jar Jar Binks", but that is something
that the WG has ruled out of scope.

  http://www.library.unr.edu/ejournals/alphaRSS.aspx

We really should use "creator" instead of "author". Author is
nonsense for photoblogs. We can do a lot of things with Atom, but
reinventing Dublin Core badly should not be one of those.

+1 for multiple author elements.
+1 for "creator" instead of "author", if anyone wants to go there.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 20 May 2005 20:46:37 +0200

* Eric Scheid <[email-masked]> [2005-05-20 20:10]:
> > define a default category to be assumed in absence of
> > explicit category elements in the document? If we do, do we
> > define such a default?
> 
> The simplest thing that could possibly work is to say that if
> there is no <category> element inside the <contributor> then
> assume a default of @term="author" with unspecified @scheme and
> unspecified @label.
> 

Sounds fine; but you did not directly address the question of
whether we define any default semantics. The absence of
atom:category and <category term="author" /> mean the same thing
per your proposal. You did effectively specify a term “author”
with particular semantics, if only implicitly.

My question is: do we define even as much?

Background: we could say something like “The given contributor is
to be assumed to be an author of the entry in absence of an
atom:category stating otherwise.” which avoids defining any terms
at all, even implicitly.

To get to the point: if we do define one term, do we define more
of them as well? Such as “editor,” “correspondent” or whatever?

This is the only reason I’m at all wary of the proposition. The
infrastructure it supplies is sound and very elegant, but the
infrastructure per se is hollow scaffolding without the semantics
it is supposed to carry, and I feel really uncomfortable about
the idea of getting into that semantics game. Particular at this
so very late stage.

If we can find an approach that avoids getting into that can of
worms, I’m definitely in support of the idea. If we cannot stay
away from it, then allowing multiple atom:author elements and
leaving any additional complexities to extension elements would
be the simpler thing to do.

Regards,
-- 
Aristotle