Re: Fetch me an author. Now, fetch me another author.
On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid [EMAIL PROTECTED] wrote: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the contributors? +1. This makes very much sense to me from a publishing company point of view. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fetch me an author. Now, fetch me another author.
On 5/22/05, Graham [EMAIL PROTECTED] wrote: On 21 May 2005, at 4:23 pm, Robert Sayre wrote: What document is impossible to express with the current syntax? At this point, it's impossible to express anything, since several of us are no longer sure what the meanings of atom:author and atom:contributor are meant to be. No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
On 22 May 2005, at 1:09 pm, Robert Sayre wrote: No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. No, we just read it a different way to what you do, the obvious way. The idea that atom:autho and atom:contributor are independent is just about a valid reading but completely counter-intuitive. There is a problem here. Graham
Re: Fetch me an author. Now, fetch me another author.
On 22/5/05 10:09 PM, Robert Sayre [EMAIL PROTECTED] wrote: What document is impossible to express with the current syntax? At this point, it's impossible to express anything, since several of us are no longer sure what the meanings of atom:author and atom:contributor are meant to be. No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. Robert, humour us, please express the following use case in format-08 syntax... Publish an entry which indicates multiple people who are to be known as an author of the entry, and distinguish them from some number of persons who are to be known as a contributor to the entry (while not actually being authors). Their contributions might be background research, for example. Refer to sections 4.2.1 and 4.2.3 for the meanings of author and contributor. e.
Re: Fetch me an author. Now, fetch me another author.
On 5/22/05, Graham [EMAIL PROTECTED] wrote: On 22 May 2005, at 1:09 pm, Robert Sayre wrote: No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. No, we just read it a different way to what you do, the obvious way. The idea that atom:autho and atom:contributor are independent is just about a valid reading but completely counter-intuitive. There is a problem here. Yes, the problem is that you think you are going to 'get it right' if you continue to work on it. I favor the path suggested by Antone in his excellent thread 'I wanna go home'.[0] I don't agree with all of the resolutions, but they're not so bad, and they could be accomplished quickly. Absurd rehashing of dates and id arguments are not going to be resolved this year. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg15526.html
Sorry. (was: Fetch me an author. Now, fetch me another author.)
On 5/22/05, Robert Sayre [EMAIL PROTECTED] wrote: It seems reasonable to conclude you people can't read. This statement was completely inappropriate. Everyone will miss requirements when they read a draft. The fact that everyone missed this requirement, no matter how obvious it is under scrutiny, indicates that this editor erred in some way. I'm not sure how it could have been clearer without the benefit of hindsight, but that doesn't justify the quoted sentence above. I apologize. Robert Sayre
Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)
Can you tell me, in those unusual cases when there is difficulty in determining which instance came last, what the heck am I supposed to do if the users expect to always see the most recent instance? Bob: The same thing you'd do if you had two entries with matching ids and modified dates. -- Roger Benningfield
Re: Fetch me an author. Now, fetch me another author.
Tim Bray wrote: A scan of the archives reveals no discussion; i.e. this rule is something that predates the move to the IETF. I believe that (with a bit of offline help) I can explain the reasoning though. We were trying to borrow the Dublin Core semantics, wherein there is the notion of an Entity Primarily Responsible, dc:creator. So, Atom gives you that with atom:author and the notion of a contributor in atom:contributor. I also scanned the archives and found no consensus. Let me speak as a victim of a few years in the publishing-software trenches: The semantics of author and contributor are a tangled mess, a real swamp, and I don't think that Atom is going to do a very good job of solving them. In particular, I don't think we're going to a better job than Dublin Core. That is to say, if we were to do as some suggest (nuke atom:contributor and make atom:author repeatable) I'm quite certain that we could come up with all sorts of corner cases and problems, probably about as many as with the current setup. I observe this is one of the problems with borrowing semantics without attribution and without consultation. You might be quite certain, but the fact is we don't know. So, bearing that in mind, and also bearing in mind Paul's recent essay on process, I'm strongly -1 on any change whatsoever to the current definition of author and contributor. -Tim As co-chair, please instruct the editors to add spec text mentioning this rationale, it is hardly satisfactory to have that constraint in there as it stands. It's tempting now to perform due diligence, and go through every constraint in the spec and cross-reference consensus. cheers Bill
Re: Fetch me an author. Now, fetch me another author.
On 21 May 2005, at 1:59 am, Tim Bray wrote: Let me speak as a victim of a few years in the publishing-software trenches: The semantics of author and contributor are a tangled mess, a real swamp, and I don't think that Atom is going to do a very good job of solving them. In particular, I don't think we're going to a better job than Dublin Core. Why are we using author instead of creator then? The current setup is a rushed kludge that came about before we started thinking things through, not a conscious decision to echo Dublin Core. That is to say, if we were to do as some suggest (nuke atom:contributor and make atom:author repeatable) I'm quite certain that we could come up with all sorts of corner cases and problems, probably about as many as with the current setup. You can say that about anything. A flat list of people associated with an entry is infinitely better than the weird one author/multiple contributors model that doesn't offer a clear way to cope with the common model of multiple co-authors. Graham
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, Graham [EMAIL PROTECTED] wrote: You can say that about anything. A flat list of people associated with an entry is infinitely better than the weird one author/multiple contributors model that doesn't offer a clear way to cope with the common model of multiple co-authors. Ben Lund is okay with the current draft: http://www.imc.org/atom-syntax/mail-archive/msg15380.html Why aren't you? Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote: Tim Bray wrote: A scan of the archives reveals no discussion; i.e. this rule is something that predates the move to the IETF. I believe that (with a bit of offline help) I can explain the reasoning though. We were trying to borrow the Dublin Core semantics, wherein there is the notion of an Entity Primarily Responsible, dc:creator. So, Atom gives you that with atom:author and the notion of a contributor in atom:contributor. I also scanned the archives and found no consensus. I can point you to many discussions surrounding atom:author. Here's one: http://www.imc.org/atom-syntax/mail-archive/msg13793.html The requirement made it through nine drafts, much discussion, and two last calls. I don't think you have a consensus argument. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
On 21 May 2005, at 3:30 pm, Robert Sayre wrote: On 5/21/05, Graham [EMAIL PROTECTED] wrote: The appropriate way to decode this is Written by Graham with contributions from Friend 1 and Friend 2 Lets decode your sample in the same way: Written by Yuri Fialko, David Sandwell, Mark Simons Paul Rosen with contributions from Yuri Fialko, David Sandwell, Mark Simons and Paul Rosen Which makes no sense. The two usages are incompatible, and the spec needs to say which is correct. What makes you think 'authorship' is arrived at by composing atom:author and atom:contributor elements. It's the impression I've had for nearly 2 years. If I'm wrong, then fine, but there's nothing in the spec that says anything either way. Graham
Re: Fetch me an author. Now, fetch me another author.
It's the impression I've had for nearly 2 years. If I'm wrong, then fine, but there's nothing in the spec that says anything either way. Well, there's nothing in the spec that explicitly separates atom:author from lots of elements. Your impression is not in the spec. I do think you're right about the wording of atom:author, though. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote: I also scanned the archives and found no consensus. I can point you to many discussions surrounding atom:author. Thanks for the offer, but I've already done that for myself. I don't much care for the number of discussions, I care about this specification and whether it has consensus. Can you find one discussion that addresses cardinality? Most of the ones I saw when I grepped through the archives seemed to focus on feed/entry inheritance. Here's one: http://www.imc.org/atom-syntax/mail-archive/msg13793.html The requirement made it through nine drafts, much discussion, and two last calls. I don't think you have a consensus argument. If you don't think I have a consensus argument, you should be able to demonstrate that by pointing me at consensus. Look. I understand the process more or less says we're done, I read Paul's mail, and as the editor I do appreciate your sentiments and opinion on this. If there is consensus and I missed it, I'll withdraw and apologise for distracting the WG. If an IETF process wizard says it's too late now, technically or in the spirit of things, I'll withdraw. If the WG makes it known that at this point in the process, I have to like them apples, we're shipping, I'll withdraw. Otherwise as a WG member I'm of the opinion that letting a specification get through that has no consensus, and that we know has no consensus, is irresponsible. cheers Bill
Re: Fetch me an author. Now, fetch me another author.
On 22/5/05 12:25 AM, Graham [EMAIL PROTECTED] wrote: Ben Lund is okay with the current draft: http://www.imc.org/atom-syntax/mail-archive/msg15380.html Why aren't you? Because what you presented to him makes no sense against the current draft. [...] Which makes no sense. The two usages are incompatible, and the spec needs to say which is correct. what if author in that example was renamed to byline (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the contributors? using that model (in that message) without renaming the author element will only be confusing. e.
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote: If there is consensus and I missed it, I'll withdraw and apologise for distracting the WG. If an IETF process wizard says it's too late now, technically or in the spirit of things, I'll withdraw. If the WG makes it known that at this point in the process, I have to like them apples, we're shipping, I'll withdraw. Otherwise as a WG member I'm of the opinion that letting a specification get through that has no consensus, and that we know has no consensus, is irresponsible. Well, this is all process bullshit. What is the technical problem? What document is impossible to express with the current syntax? Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
* Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), +1, calling it author when that sort of usage is expected and encouraged is a lie. and some mechanism introduced to indicate the nature of the contribution by each of the contributors? Allowing atom:category would be nice, though I think we can punt on that. Regards, -- Aristotle
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), What are you talking about? Please refrain from complaining your pet semantics aren't in the draft. Here are some simple questions, which you can answer by reading the example I gave, and reading the draft. http://www.imc.org/atom-syntax/mail-archive/msg15380.html Who is the author of that entry? Who are the contributors? There is no mention of 'byline'. You are complaining that you can't have multiple 'authors' for some definition of 'author', because of element cardinality. I observe that Ben Lund's example, with multiple dc:creator elements, was a failure. Multiple author elements failed the science journal use case, the basis of your original objection. format-08 works. I fully agree that other ways of arranging authors and contributors are possible and reasonable, but no one has demonstrated a document that format-08 can't cover. At this stage, changing the spec to suit religious preferences would be extremely arrogant. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
On 22/5/05 2:51 AM, Robert Sayre [EMAIL PROTECTED] wrote: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the contributors? What are you talking about? Please refrain from complaining your pet semantics aren't in the draft. It wasn't a complaint, it was a suggestion, and it was directed more to Graham than to you. Here's a free cluepon: what if [...] Here are some simple questions, which you can answer by reading the example I gave, and reading the draft. http://www.imc.org/atom-syntax/mail-archive/msg15380.html Who is the author of that entry? Who are the contributors? The problem with the example you gave is that it suggests that even entries with just the one author/contributor would need two person constructs in the entry, or maybe just the one ... either way it's confusing. Also, more importantly, how do you then indicate which individuals listed as contributor have an author credit and which individuals were only contributors. Consider this example (and please note that the second line isn't the literal bits on the wire): entry authorname# a list of THREE names #/name/author contributornameBob Bellows/nameuriB.html/uri/contributor contributornameFred Fellows/nameuriF.html/uri/contributor contributornameJon Jello/nameuriJ.html/uri/contributor contributornameAda Aiello/nameuriA.html/uri/contributor [...] /entry Now, this *is* a valid format-08 document, right? BUT can you tell me who the THREE authors are, and who the fourth person is who is only a contributor (and not an author)? So: valid format-08, but junk data. There is no mention of 'byline'. There most certainly is a mention of the thing I have referred to elsewhere as a byline. It happens to be serialised within authorname. Instead of the literal element name byline I could just as easily use the literal element name of authorship. format-08 works. for some definition of works ... like passes the validator, but not provides meaningful semantics. I fully agree that other ways of arranging authors and contributors are possible and reasonable, but no one has demonstrated a document that format-08 can't cover. can we shoe-horn data into elements? sure. would that document then pass the validator? sure can we extract that data in a meaningful sense? no. At this stage, changing the spec to suit religious preferences would be extremely arrogant. Oh, please, stop trolling. e.
Re: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: I fully agree that other ways of arranging authors and contributors are possible and reasonable, but no one has demonstrated a document that format-08 can't cover. The Atom Syndication Fformat spec has two authors and many contributors. Limiting to one author, you can't distinguish between the authors and contributors. +1 on allowing multiple atom:author -1 to dropping atom:contributor -1 to renaming atom:author (I did already say I was +1 on having deterministic content model and according care to element ordering but that's not really the point here) atom:entry atom:titleThe Atom Syndication Format/atom:title atom:subtitledraft-ietf-atompub-format-08/atom:subtitle atom:author atom:nameMark Nottingham/atom:name atom:email[EMAIL PROTECTED]/atom:email atom:urihttp://www.mnot.net//atom:uri /atom:author atom:author atom:nameRobert Sayre/atom:name atom:email[EMAIL PROTECTED]/atom:email atom:urihttp://boswijck.com/atom:uri /atom:author atom:contributor atom:nameTim Bray/atom:name /atom:contributor atom:contributor atom:nameMark Pilgrim/atom:name /atom:contributor atom:contributor atom:nameSam Ruby/atom:name /atom:contributor atom:contributor atom:nameNorman Walsh/atom:name /atom:contributor atom:content src=http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt; / /atom:entry -- Thomas Broyer
Re: Fetch me an author. Now, fetch me another author.
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]: At this stage, changing the spec to suit religious preferences would be extremely arrogant. Please stop talking to people about process bullshit at one occasion and turning around to chide others for at this stage at the next. Regards, -- Aristotle
Re: Fetch me an author. Now, fetch me another author.
Thomas Broyer wrote: +1 on allowing multiple atom:author -1 to dropping atom:contributor -1 to renaming atom:author +1 to that. -- Anne van Kesteren http://annevankesteren.nl/
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]: At this stage, changing the spec to suit religious preferences would be extremely arrogant. Please stop talking to people about process bullshit at one occasion and turning around to chide others for at this stage at the next. As I said before, it doesn't matter if the spec is perfect if it takes forever. Making up requirements after last call is out of order. Eric is making up requirements and adding category elements to author elements. It is beyond ridiculous. Pardon me if I'm getting impatient, but I don't think any of the ideas raised in the past few days are critical improvements to the format. In fact, all I see is people twiddling their beanies about semantics, rather than explaining why they need X for their products (Wyman excluded--note that he raised his atom:id issue in last call). Bob's bits-on-the-wire approach to multiple ids is fine. We can put the DOS issue in the security concerns, but it really comes down to don't believe everything you read on the internet. The current suggested text makes the terrible mistake of conflating atom:id and timestamps. I remember Graham once tried to re-raise the atom:modified idea, and was told that he was very close to being out-of-order. Well, it certainly is now. Not only is it offensive, but there's no reason to expect it will work, and no reason it couldn't be added if it does happen to work. So, really, we have folks who want to delay this spec because they think they've solved Distributed Versioning On The Internet. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
Eric Scheid wrote: I'm +0.5 to all that ... the sticky problem is just how do we insert an authorship string like Raggett, D, Hors, A, and I Jacobs into an entry, and I'm -1 on using an extension for that since there is a $17 billion industry already using feeds that really wants to be able to insert that kind of authorship string. You don't, but it can be built from multiple atom:author elements: atom:authoratom:nameRagget, D/atom:name/atom:author atom:authoratom:nameHors, A/atom:name/atom:author atom:authoratom:nameI Jaccobs/atom:name/atom:author ...but we might need atom:author elements to be ordered... -- Thomas Broyer
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, Phil Ringnalda [EMAIL PROTECTED] wrote: Thomas Broyer wrote: The Atom Syndication Fformat spec has two authors and many contributors. Limiting to one author, you can't distinguish between the authors and contributors. Actually, no. It has one author, a corporation, or similar entity, the ATOMPUB Working Group, and two editors and many contributors. (Editorial nit: -08 says it's a product of the Network Working Group, apparently the xml2rfc default for workgroup). http://www.rfc-editor.org/rfcfaq.html 2) Every RFC is attributed to the Network Working Group. What working group is that? This label in the heading of every RFC is historical in form and symbolic in content. Historically, network working group meant the set of researchers who developed the packet switching protocols for the ARPAnet, beginning in 1969. This label is maintained on RFCs as a reminder of the long and significant technical history that is recorded in the RFC series, and as a reminder that today's technical decisions, wise or not, may be with us for many years. Today, the Network Working Group should be interpreted as the set of users, vendors, and researchers who are working to improve and extend the Internet, in particular under the ISOC/IETF umbrella. -- Of course, the entity primarily responsible for the draft is the IETF, and the internet community. A theory: no one who thought IETF last call meant we were done is reading the list anymore, so all we have left are people intent on descending every rathole and continuing to work on the spec until it becomes a suitably ornate design-by-committee monster. Robert Sayre
Re: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: On 5/21/05, Phil Ringnalda [EMAIL PROTECTED] wrote: Actually, no. It has one author, a corporation, or similar entity, the ATOMPUB Working Group, and two editors and many contributors. (Editorial nit: -08 says it's a product of the Network Working Group, apparently the xml2rfc default for workgroup). http://www.rfc-editor.org/rfcfaq.html 2) Every RFC is attributed to the Network Working Group. Bah. I was confused by the way some WGs list themselves while it's still an I-D, and some don't. I'll go back to my corner now. Phil Ringnalda
Re: Fetch me an author. Now, fetch me another author.
On 22/5/05 3:38 AM, Robert Sayre [EMAIL PROTECTED] wrote: The problem with the example you gave is that it suggests that even entries with just the one author/contributor would need two person constructs in the entry, or maybe just the one ... either way it's confusing. No, it doesn't. Why are you saying it suggests that? OK, answer me this: if an entry has only one person associated with it, do we write it with just a lone author element, or do we write it with an author element *and* a contributor element? What if there was one person who wrote the text, and two people who provided suggestions or feedback or research (etc) but did not write any of the text, and the publisher wishes to acknowledge their valuable input ... one author and two contributors, or one author and three contributors? Also, more importantly, how do you then indicate which individuals listed as contributor have an author credit and which individuals were only contributors. Why are you mapping elements to types of credit? Are you seriously playing these word games for the sheer hell of it? Let me try rephrasing to something more literal: how do you then indicate which individuals listed as a contributor could be referred to as an author, and which individuals are contributors but not author? There is nothing in the spec that suggests they map to types of credit. As I said, please read the draft. bullshit. format-08 says: The atom:author element is a Person construct that indicates the author of the entry or feed. ^ and The atom:contributor element is a Person construct that indicates a person or other entity who contributed to the entry or feed. ^^ Now, unless you can point to the place in the spec which re-defines those two words in the English language, then we must assume they mean what they commonly mean. They *don't* mean the same thing. The *don't* mean the same thing. If they did, we wouldn't need two elements, now would we? Seriously, 2 more months of this crap to solve a 'problem' which you can't give an example of. I've previously given examples in a round a bout way. Let me be more explicit for you then: Publish an entry which indicates multiple people who are to be known as an author of the entry, and distinguish them from some number of persons who are to be known as a contributor to the entry (while not actually being authors). Their contributions might be background research, for example. Refer to sections 4.2.1 and 4.2.3 for the meanings of author and contributor. You might have a perfect spec, but no one will care if it is never done. I'm not looking for a perfect spec. I'm hoping for a *useful* spec, one applicable to some very real real-world use cases. Getting a feed document to validate is nice, but it's not the end goal -- we must be able to *extract* the data meaningfully. e.
Re: Fetch me an author. Now, fetch me another author.
On Saturday, May 21, 2005, at 04:08 PM, Robert Sayre wrote: You think you'll be able to disambiguate entries by adding a more-specific date field, making for two date fields. I think you can disambiguate entries by adding any number of extension fields. That's great. Add extensions. +1 -- those who need this can use an extension. Those who either don't publish multiple instances of entries with the same atom:updated in the same document or don't care about the ordering among those don't have to bother with it. I'm a little uncomfortable with the idea of introducing a date/time element whose purpose is to convey a sequence rather than a timestamp. It feels like major overkill with respect to what the data really means, which makes me think it's not the right solution. Besides, I want to get Atom 1.0 finished.
RE: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: atom:modified cannot be operationally distinguished from atom:updated. Obviously, if people start shipping feeds with the same id and atom:updated figure, it will be needed. There's no reason to standardize it, though. We don't know how that would work. The definition of atom:updated was explicitly and intentionally crafted to permit the creation of multiple non-identical entries that shared common atom:id and atom:updated values. Clearly, it was the intention of the Working Group to permit this, otherwise the definition of atom:updated would not be as it is. Thus, it is ridiculous to try to suggest that feeds with the same id and atom:updated are somehow unanticipated or not-understood. If such feeds are so far outside the ken of what the working group intends, then atom:updated should never have been defined as it is. Additionally, atom:modified is clearly distinguished from atom:updated *by definition!* Atom:modified indicates that last time an entry was modified. Atom:updated indicates the last time it was modified in a way that the publisher considered significant. This is a very clear distinction. bob wyman
Re: Fetch me an author. Now, fetch me another author.
The definition of atom:updated was explicitly and intentionally crafted to permit the creation of multiple non-identical entries that shared common atom:id and atom:updated values. Clearly, it was the intention of the Working Group to permit this, otherwise the definition of atom:updated would not be as it is. Thus, it is ridiculous to try to suggest that feeds with the same id and atom:updated are somehow unanticipated or not-understood. If such feeds are so far outside the ken of what the working group intends, then atom:updated should never have been defined as it is. Additionally, atom:modified is clearly distinguished from atom:updated *by definition!* Atom:modified indicates that last time an entry was modified. Atom:updated indicates the last time it was modified in a way that the publisher considered significant. This is a very clear distinction. Bob, that's exactly right. The definitions are very different, and this is not an issue that arises with the allowance for multiple atom:ids in one feed document. Here's the last time this discussion happened: http://www.imc.org/atom-syntax/mail-archive/msg13276.html Robert Sayre
RE: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: Here's the last time this discussion happened: http://www.imc.org/atom-syntax/mail-archive/msg13276.html Tim's point in the referenced mail supported the current definition of atom:updated which provides a means for publishers to express their own subjective opinions of what is a significant change to an entry. However, the solution of one problem does not eliminate the second problem. The second problem is that readers (not publishers) need to be able to distinguish and temporally order entries that have been written by publishers. Because the publishers CANNOT know the detailed needs of all their readers, publishers' subjective input cannot be held to be useful. Objective metrics which can be clearly understood by both publishers and readers must be used. In this case, the best objective measure to use is to say that the change of one of more bits in the encoding or representation of an entry should result in a new atom:modified value. * Atom:updated addresses needs of publishers * Atom:modified addresses needs of readers Both sets of needs, that of publishers as well as readers, must be addressed and dealt with by the Atom format. Atom:updated only addresses the needs of publishers. bob wyman
Re: Fetch me an author. Now, fetch me another author.
On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Objective metrics which can be clearly understood by both publishers and readers must be used. In this case, the best objective measure to use is to say that the change of one of more bits in the encoding or representation of an entry should result in a new atom:modified value. * Atom:updated addresses needs of publishers * Atom:modified addresses needs of readers Both sets of needs, that of publishers as well as readers, must be addressed and dealt with by the Atom format. Atom:updated only addresses the needs of publishers. The WG rejected 'objective dates' with prejudice. I'm reminded of this discussion: http://www.imc.org/atom-syntax/mail-archive/msg10954.html You know, the one where we rejected atom:modified after considering all of the same issues we're discussing now. Robert Sayre
RE: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)
Antone Roundy wrote: Unless the need for this can be shown, and it can be shown that an extension can't take care of it, I'm -1 on atom:modified. The need is simple and I've stated it dozens of times... Given two non-identical entries that share the same atom:id and the same atom:updated, I need to know which of them is to be presented to the user. The current specification doesn't allow me to do anything other than make a random choice. This is not reasonable. Atom:modified would provide the data needed to determine which was the most recently produced of the two entries. That most recently produced entry is the one that is most often desired by users. On extensions... Virtually anything can be done in extensions. If nothing should be in the core except those things that can be defined by extensions, then nothing would be in the core. It is inevitable that extensions will not be as broadly implemented as elements of the core. The practical implication of forcing something to be an extension is to ensure that it is never broadly implemented. bob wyman
Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)
On Saturday, May 21, 2005, at 09:20 PM, Bob Wyman wrote: Antone Roundy wrote: Unless the need for this can be shown, and it can be shown that an extension can't take care of it, I'm -1 on atom:modified. The need is simple and I've stated it dozens of times... ...but is it a need or a want? That was the point need in quotes was attempting to make. I agree it is preferred to be able to reliably pick the last one, but I disagree that it's a particularly important preference. Common practice is, and will probably continue to be, to include only one instance of a particular entry in a particular feed document. Only in the unusual cases will there be any difficulty in determining which instance came last. On extensions... Virtually anything can be done in extensions. Many things can, but not all. An extension can't say I'm not going to publish a title, because I have roundy:title++, which is better. atom:title is required. Also, an extension won't be able to allow multiple atom:author elements if we don't amend the spec to allow them. It will be able to define an alternative way of expressing authorship, and allow multiple of those, but a single author will continue to be required, either at the feed level or in the entry. What I meant was particularly without duplicating the function of a core element, which just makes things sloppy. It is inevitable that extensions will not be as broadly implemented as elements of the core. The practical implication of forcing something to be an extension is to ensure that it is never broadly implemented. It makes it more rare, certainly, but there are extensions which are broadly implemented, and I'm sure there will be more, if the need is significant enough to enough people.
Re: Fetch me an author. Now, fetch me another author.
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 21:25]: On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]: At this stage, changing the spec to suit religious preferences would be extremely arrogant. Please stop talking to people about process bullshit at one occasion and turning around to chide others for at this stage at the next. As I said before, it doesn't matter if the spec is perfect if it takes forever. [] Pardon me if I'm getting impatient, but I don't think any of the ideas raised in the past few days are critical improvements to the format. [] I remember Graham once tried to re-raise the atom:modified idea, [] And all of these of these are good points, but none of this is what Im talking about. What Im talking about is is merely that you keep using the process argument in whichever way will most likely lead to the result youre in favour of. Its irritating and detracts from your factual arguments, which are consistent. That is all. Regards, -- Aristotle
