Re: multiple atom:author elements?
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-20 20:10]: > On 21/5/05 3:41 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > > 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? > > The simplest thing that could possibly work is to say that if > there is no element inside the 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? Sounds fine; but you did not directly address the question of whether we define any default semantics. The absence of atom:category and 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
Re: multiple atom:author elements?
--On Friday, May 20, 2005 09:33:01 AM -0400 Robert Sayre <[EMAIL PROTECTED]> wrote: 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? 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
Re: multiple atom:author elements?
On 21/5/05 4:17 AM, "Graham" <[EMAIL PROTECTED]> wrote: > Well unless we make category/term machine readable, we might as well > just have a plain text blob. it is machine readable: 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.
Re: multiple atom:author elements?
* Graham <[EMAIL PROTECTED]> [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
Re: multiple atom:author elements?
On 5/20/05, Danny Ayers <[EMAIL PROTECTED]> wrote: > 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. Here is a new example for the spec. Is there a use case that's not covered? http://purl.org/atom/ns#draft-ietf-atompub-format-09";> dive into mark A lot of effort went into making this effortless 2005-04-02T12:29:29Z tag:example.org,2003:3 http://example.org/"/> Copyright (c) 2003, Mark Pilgrim http://www.example.com/"; version="1.0"> Example Toolkit Atom draft-07 snapshot http://example.org/2005/04/02/atom"/> http://example.org/audio/ph34r_my_podcast.mp3"/> tag:example.org,2003:3.2397 2005-04-02T12:29:29Z 2003-12-13T08:29:29-04:00 Mark Pilgrim, et al. Mark Pilgrim http://example.org/ [EMAIL PROTECTED] Sam Ruby Joe Gregorio http://diveintomark.org/";> http://www.w3.org/1999/xhtml";> [Update: The Atom draft-07 snapshot is out.]
Re: multiple atom:author elements?
>> Does anyone remember the reason we have atom:contributor? I say drop it. this is instructive reading... http://www.intertwingly.net/wiki/pie/NumberOfAuthorsDiscussion > If we do allow multiple s, we could ditch and at > the same time lessen the likelihood of ugliness like: > > Raggett, D, Hors, A, and I Jacobs that string inside is ugly. that string inside is desired* e. * by some publishers, who by convention have the requirement that contributors be listed in some proper order.
Re: multiple atom:author elements?
On 20 May 2005, at 6:19 pm, Eric Scheid wrote: actually, I'm liking this more and more, because... Barnable Foo <.../> Well unless we make category/term machine readable, we might as well just have a plain text blob. Graham
Re: multiple atom:author elements?
On 21/5/05 3:41 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > 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? The simplest thing that could possibly work is to say that if there is no element inside the 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.
Re: multiple atom:author elements?
On 5/20/05, Graham <[EMAIL PROTECTED]> wrote: > 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 s, we could ditch and at the same time lessen the likelihood of ugliness like: Raggett, D, Hors, A, and I Jacobs 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 s: +1 removing : +1 Cheers, Danny. -- http://dannyayers.com
Re: multiple atom:author elements?
* Eric Scheid <[EMAIL PROTECTED]> [2005-05-20 17:50]: > > > Barnable Foo > <.../> > +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
Re: multiple atom:author elements?
On 21/5/05 1:35 AM, "Eric Scheid" <[EMAIL PROTECTED]> wrote: > > > Barnable Foo > <.../> > actually, I'm liking this more and more, because... Barnable Foo <.../> (Just in case it's not obvious, my use of the elements above describe the nature of *contribution* of that person to that entry, and not a sense of identity for that person.) e.
Re: multiple atom:author elements?
On 21/5/05 12:36 AM, "David Powell" <[EMAIL PROTECTED]> wrote: > 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. That feed/entry inheritance thing is going to bite us again, I'm sure. e.
Re: multiple atom:author elements?
On 21/5/05 12:49 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > 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. I'm liking this idea. The main thing we'd want to fish out of (sic) would be ... which would be renamed to be . All the nitty gritty details on each person involved would then be described in multiple 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: this is the title Foo, Bar, and Fum Barnable Foo <.../> Sir Ignacious Bar, Esq. <.../> Fred Fum <.../> Some guy <.../> Or ... and this is a crazy idea ... we could instead support inserting inside the element, thus even allowing us to link to a controlled schema, just in case people have lots of funky roles. Barnable Foo <.../> e.
Re: multiple atom:author elements?
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 & 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
Re: multiple atom:author elements?
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > Robert Sayre wrote: > > On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > > > > > >>I really don't want to see this in an Atom feed: > >> > >>Raggett, D, Hors, A, and I Jacobs > > > > > > *gasp. multiple nouns inside a single element. > > *gasp. multiple nouns inside a single noun 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. > > I see why that's problem. For example you could recreate that string > 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
Re: multiple atom:author elements?
Robert Sayre wrote: I meant Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen http://research.example.org/dept/ Yuri Fialko http://research.example.org/dept/fialko/ David Sandwell http://research.example.org/dept/sandwell/ Mark Simons http://research.example.org/dept/simons/ Paul Rosen http://research.example.org/dept/rosen/ ... Okay, cool. I like that too... Ta, Ben 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
Re: multiple atom:author elements?
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote: > Robert Sayre wrote: > > 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. > > > > I meant Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen http://research.example.org/dept/ Yuri Fialko http://research.example.org/dept/fialko/ David Sandwell http://research.example.org/dept/sandwell/ Mark Simons http://research.example.org/dept/simons/ Paul Rosen http://research.example.org/dept/rosen/ ... Robert Sayre
Re: multiple atom:author elements?
* Ben Lund <[EMAIL PROTECTED]> [2005-05-20 15:04+0100] > > Robert Sayre wrote: > >On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > > >>Eric Scheid wrote: > >> > >> > >>>Science Journals are just one example of feeds which require being able > >>>to > >>>specify multiple authors per entry. > >> > >>Legal documents and legislation are others. Good catch Eric. I'll > >>support this. > > > > > >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? > > I find it astonishing that you dismiss publishing markets amounting to > approximately $17 billion annually [1], [2]. +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 > 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 >
Re: multiple atom:author elements?
Robert Sayre wrote: 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. You mean: Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen Yuri Fialko David Sandwell Mark Simons Paul Rosen ? I like that structure. Ta, Ben 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
Re: multiple atom:author elements?
On 5/20/05, David Powell <[EMAIL PROTECTED]> wrote: > > 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. Hmmm. That's true. There also seems to be a stigma attached to atom:contributor. > > Mark Nottingham and Robert Sayre > Mark Nottingham > Robert Sayre > > > 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. 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. > > Bad example :) > > from= "From:" mailbox-list CRLF Doh! RFC2822 can be so harsh. Robert Sayre
Re: multiple atom:author elements?
On Fri, May 20, 2005 at 10:09:07AM -0400, Robert Sayre wrote: > > 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? > > We better do something about that from: header in email, too. Just > 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 PROTECTED] uncertaintydivision.org
Re: multiple atom:author elements?
Friday, May 20, 2005, 3:09:07 PM, Robert Sayre wrote: > I'm not dismissing them. I'm saying they should use an extension, > 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: Mark Nottingham and Robert Sayre Mark Nottingham Robert Sayre 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. >> 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? > We better do something about that from: header in email, too. Just > pick a string. That's all you have to do. Bad example :) from= "From:" mailbox-list CRLF -- Dave
Re: multiple atom:author elements?
Robert Sayre wrote: On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: Legal documents and legislation are others. Good catch Eric. I'll support this. 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 in the format and evaluate their fitness for scientific journals, legal documents, and legislation? Unfair :\ Not the least because you're assuming that hasn't been done. cheers Bill
Re: multiple atom:author elements?
Robert Sayre wrote: On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote: 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? [3] http://www.nature.com/nature/current_issue/rss 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 Robert Sayre http://dx.doi.org/10.1038/nature03425";> Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit http://dx.doi.org/10.1038/nature03425 Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit Yuri Fialko David Sandwell Mark Simons Paul Rosen doi:10.1038/nature03425 Nature 435, 295 (2005) Nature 435 7040 Article 295 299 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
Re: multiple atom:author elements?
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote: > 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? > > [3] http://www.nature.com/nature/current_issue/rss Ooh. Actually, this is quite interesting. What's up with that description field? Robert Sayre http://dx.doi.org/10.1038/nature03425";> Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit http://dx.doi.org/10.1038/nature03425 Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit Yuri Fialko David Sandwell Mark Simons Paul Rosen doi:10.1038/nature03425 Nature 435, 295 (2005) Nature 435 7040 Article 295 299
Re: multiple atom:author elements?
On 5/20/05, Ben Lund <[EMAIL PROTECTED]> wrote: > Robert Sayre wrote: > > On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > > >>Eric Scheid wrote: > >> > >> > >>>Science Journals are just one example of feeds which require being able to > >>>specify multiple authors per entry. > >> > >>Legal documents and legislation are others. Good catch Eric. I'll > >>support this. > > > > > > 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? > > I find it astonishing that you dismiss publishing markets amounting to > 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. > 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? 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
Re: multiple atom:author elements?
Robert Sayre wrote: On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: Eric Scheid wrote: Science Journals are just one example of feeds which require being able to specify multiple authors per entry. Legal documents and legislation are others. Good catch Eric. I'll support this. 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? 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
Re: multiple atom:author elements?
On 5/20/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > Eric Scheid wrote: > > > 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? > > Legal documents and legislation are others. Good catch Eric. I'll > support this. 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
Re: multiple atom:author elements?
On 20/5/05 9:51 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> Raggett, D, Hors, A, and I Jacobs > > *gasp. multiple nouns inside a single element. > > I don't see why that's a problem. Try then importing those article feeds and producing an a-z index by author. e.
Re: multiple atom:author elements?
Robert Sayre wrote: On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote: I really don't want to see this in an Atom feed: Raggett, D, Hors, A, and I Jacobs *gasp. multiple nouns inside a single element. *gasp. multiple nouns inside a single noun 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. 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
Re: multiple atom:author elements?
On 5/20/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > I really don't want to see this in an Atom feed: > > Raggett, D, Hors, A, and I Jacobs *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
Re: multiple atom:author elements?
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 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. 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
Re: multiple atom:author elements?
Robert Sayre wrote: -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. 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
Re: multiple atom:author elements?
Eric Scheid wrote: 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? Legal documents and legislation are others. Good catch Eric. I'll support this. cheers Bill
Re: multiple atom:author elements?
On 5/19/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > 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. -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
Re: multiple atom:author elements?
> >>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. +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
Re: multiple atom:author elements?
Eric Scheid wrote: On 20/5/05 2:10 PM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: 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. 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: Raggett, D, Hors, A, and I Jacobs (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
Re: multiple atom:author elements?
On 20/5/05 2:10 PM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > 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. 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: Raggett, D, Hors, A, and I Jacobs (perfectly acceptable for display, but not for data) e.
Re: multiple atom:author elements?
* Antone Roundy <[EMAIL PROTECTED]> [2005-05-19 22:10-0600] > > On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: > >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? > > 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. 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
Re: multiple atom:author elements?
On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: 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? 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.
multiple atom:author elements?
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.
