Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues
Mark Pilgrim wrote: On 5/19/05, Tim Bray [EMAIL PROTECTED] wrote: [atom:summary and accessibility] Right now our draft says: atom:entry elements MUST contain an atom:summary element in any of the following cases: ... - the atom:entry contains an atom:content that has a src attribute (and is thus empty). - the atom:entry contains content that is encoded in Base64; i.e. the type attribute of atom:content is a MIME media type [MIMEREG] and does not begin with text/ nor end with +xml. I'm saying that MUST is probably too strong here. I don't mind it personally, but I don't see the case for requiring it on grounds of interoperability. If we keep it, the format spec should probably mention *why* this is required, if only in passing. +1 Particulary on the first point above atom:content that has a src attribute, MUST is a bit heavy handed for accesibility, since the src attribute could reference an accessible resource - like an external html file. Its when src references an inaccessible resource is it essential that atom:summary convey an accessible equivalent. The second point about Base64 encoding, MUST or strongly recommended/encouraged for the purpose of accessibility is needed. In respect to Mark's suggestion of mentioning why: Perhaps 4.2.13 The atom:summary element is a good place to mention the accessibility. As an initial suggestion, after the first paragraph of The atom:summary element is a Text construct that conveys a short summary, abstract or excerpt of an entry. Insert the paragraph: In cases where atom:content is Base64 encoded, or has a src attribute, the atom:summary conveys an accessible text equivalent to the non-text atom:content. Then again, if it got changed to SHOULD, I wouldn't raise holy hell about it. But I'm not going to write a Pace to change it. That suits me fine too. Thanks, Mike
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: authornameRaggett, D, Hors, A, and I Jacobs/name/author (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?
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?
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?
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 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?
On 5/20/05, Eric Scheid [EMAIL PROTECTED] wrote: I really don't want to see this in an Atom feed: authornameRaggett, 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
Re: Editorial: rules based on MIME media types in @type attributes
On 5/20/05, Thomas Broyer [EMAIL PROTECTED] wrote: I'd like to raise this up one more time: http://www.imc.org/atom-syntax/mail-archive/msg14247.html Atom defines rules based on MIME media types in @type attributes, and I'm not sure they are actually accurate... They also don't explain the actual meaning behind the technical rules. In 4.1.3.2: [ If the value of type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. ] Replace with: [ If the value of type is a text or XML media type, that is, if it begins with text/, is one the XML Media Types [XMLMIME] or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. ] To be completely accurate, the part before the '/' is called the type, the part after the '/' is called the sub-type, so to rephrase your re-phrasing: If the value of is a text or XML media type, that is, if the type component of the mime-type is equal to text, or if the mime-type is one the XML Media Types [XMLMIME], or the mime-type's sub-type ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. -joe -- Joe Gregoriohttp://bitworking.org
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 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 linkhttp://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:creatorYuri Fialko/dc:creator dc:creatorDavid Sandwell/dc:creator dc:creatorMark Simons/dc:creator dc:creatorPaul Rosen/dc:creator dc:identifierdoi:10.1038/nature03425/dc:identifier dc:sourceNature 435, 295 (2005) /dc:source prism:publicationNameNature/prism:publicationName prism:volume435/prism:volume prism:number7040/prism:number prism:sectionArticle/prism:section prism:startingPage295/prism:startingPage prism:endingPage299/prism:endingPage /item 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: 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?
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: atom:author atom:nameMark Nottingham and Robert Sayre/atom:name dc:creatorMark Nottingham/dc:creator dc:creatorRobert 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. 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?
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: authornameRaggett, D, Hors, A, and I Jacobs/name/author *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?
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
Re: multiple atom:author elements?
On 21/5/05 1:35 AM, Eric Scheid [EMAIL PROTECTED] wrote: contributor category term=Author/ nameBarnable Foo/name .../ /contributor actually, I'm liking this more and more, because... contributor nameBarnable 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.
Re: multiple atom:author elements?
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 17:50]: contributor category term=Author/ nameBarnable Foo/name .../ /contributor +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 its the one at the entry level, it cant 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 dont, 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
editorial: software
did someone say that the spec doesn't use the word software? 6.3 Software Processing of Foreign Markup e.
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 authors, we could ditch contributor and at the same time lessen the likelihood of ugliness like: authornameRaggett, 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.
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? ?xml version=1.0 encoding=utf-8? feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-09; title type=textdive into mark/title subtitle type=html A lt;emgt;lotlt;/emgt; of effort went into making this effortless /subtitle updated2005-04-02T12:29:29Z/updated idtag:example.org,2003:3/id link rel=alternate type=text/html hreflang=en href=http://example.org// copyrightCopyright (c) 2003, Mark Pilgrim/copyright generator uri=http://www.example.com/; version=1.0 Example Toolkit /generator entry titleAtom 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/ idtag:example.org,2003:3.2397/id updated2005-04-02T12:29:29Z/updated published2003-12-13T08:29:29-04:00/published author nameMark Pilgrim, et al./name /author contributor nameMark Pilgrim/name urihttp://example.org//uri email[EMAIL PROTECTED]/email /contributor contributor nameSam Ruby/name /contributor contributor nameJoe Gregorio/name /contributor content type=xhtml xml:lang=en xml:base=http://diveintomark.org/; div xmlns=http://www.w3.org/1999/xhtml; pi[Update: The Atom draft-07 snapshot is out.]/i/p /div /content /entry /feed
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. Theres an option @scheme attribute for atom:category. Thats part of the elegance of this approach. Regards, -- Aristotle
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: 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.
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 dont, 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 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? 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 Im 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, Im 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: extension elements anywhere?
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 19:55]: 6.4Extension Elements Atom allows foreign markup anywhere in an Atom document. does this mean this is allowed: title type=texthello world!foo:evil:-)/foo:evil/title You request adding except where they are explicitly forbidden to that sentence, I suppose. The spec for Text Constructs does so for your example, anyway. Regards, -- Aristotle
Re: PROCESS QUESTION: are we done yet?
On 20 May 2005, at 8:02 pm, Paul Hoffman wrote: Does the WG want to be able to open up new topics, or re-open old topics with a twist? If so, do we all agree to the delay in publication that comes with that? Also, how long should this opening and re-opening last? Are there any limits on which parts of the spec we are willing to change? I think the last deadline was premature and totally out of sync with the WG, and if anything is responsible for the delay, because of the temporary cessation of new Paces. There probably needs to be one more round of discussion on recent changes like duplicate IDs, but everything else seems finished. I think there will be a natural ending soon enough. Graham
PaceCaching
--On Tuesday, May 17, 2005 09:13:37 PM -0700 Tim Bray [EMAIL PROTECTED] wrote: PaceCaching Multiple -1's, it fails. I'll address the objections anyway, because I (still) think this is important. 1. This introduces multiple caching schemes. Wrong. Right now we have multiple schemes, with HTTP caching, ad hoc client caching, and ad hoc server-side load shedding. This recommends one consistant scheme, which we know will work. The current multi-scheme approach is a mess, and we can be sure that it will have problems. 2. This applies protocol caching to a client. True, but not really an isssue. HTTP caching does work when used to manage a client cache. Compare a client working through an HTTP cache to one which checks the cache information internally before issuing HTTP requests. The HTTP server will see the same series of requests. Effectively, the client will run a virtual HTTP cache internally. 3. Server-side parsing is too much overhead. Maybe with 90 MHz Pentiums, but XML parsing is really fast these days. Parse the file, cache the values, and toss them if the file has changed when you stat it. Or, the blog server software can set the cache info out-of-band to the server. 4. This requires synchronized clocks. Those are a SHOULD for HTTP, too. And they ought to be a SHOULD for Atom anwyay, because you cannot date-sort entries from two servers with unsynchronized clocks. 5. This is just like HTTP-EQUIV and that has failed. Yes and no. Most HTTP servers ignore HTTP-EQUIV, but it is still useful for passing through things like content-language when there is no HTTP header present. For Atom, the caching info would be valid when there is no HTTP cache header. This is exactly where HTTP-EQUIV is effective today. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Microsoft to support Atom in any aggregator they produce
FYI: Robert Scoble, a Microsoft employee/insider very familiar with Microsoft's plans for syndication, declares in comments on his blog that we are supporting Atom in any aggregator we produce. Microsoft's example in supporting Atom should be followed by all other aggregator developers in the future and Microsoft should be commended for supporting the adoption of openly defined standards for syndication. For more info (and some heated comments...) see: http://bobwyman.pubsub.com/main/2005/05/microsoft_to_su.html bob wyman
Re: PROCESS QUESTION: are we done yet?
On 5/20/05, Graham [EMAIL PROTECTED] wrote: On 20 May 2005, at 8:02 pm, Paul Hoffman wrote: Does the WG want to be able to open up new topics, or re-open old topics with a twist? If so, do we all agree to the delay in publication that comes with that? Also, how long should this opening and re-opening last? Are there any limits on which parts of the spec we are willing to change? I think we're done. The multiple IDs issue was raised in last call and we need to resolve the wording. Everything else is fine. Robert Sayre
Re: PROCESS QUESTION: are we done yet?
Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote: Does the WG want to be able to open up new topics, or re-open old topics with a twist? If so, do we all agree to the delay in publication that comes with that? What would the minimum delay be out of interest? 4 weeks? 6 weeks? Also, how long should this opening and re-opening last? Are there any limits on which parts of the spec we are willing to change? I'd be more comfortable with another round. A major motivation of Atom was to avoid the ambiguities of RSS, so we'd better not have any ourselves. I have some concerns about these issues still: a) PaceAllowDuplicateIDs was made after Last Call and is a pretty fundamental change to the Atom model. Its effect, that entries can have multiple instances, is an invention that none of the RSS specs cover. I think that we're rushing this without having time to think what effects it might have. (I'm basically in favour of it, but I think that it needs a bit more thought). I think that the debate on atom:version/atom:modified was curtailed prematurely (within 3 days) and should be re-opened. b) Hopefully we wouldn't try to add new features to Atom if we did another round, but allowing multiple authors seems to have some merit to it. The current text inhibits multiple authors being described even by extensions. Hopefully we can get a minimal base that would allow multiple authors to be described, deferring as much as we can to extensions. Robert Sayer's suggestion looked promising, but inheritance issues would need to be considered. And a few issues that are probably editorial: c) The language introduced by PaceAllowDuplicateIDs implies important properties of entries that ought to be made explicit. Throwing the word revision/version/whatever into the spec somewhere would make things clearer, and would be a useful vocabulary term for people who plan to write further specifications for extensions etc. (In the same way that Jeff Mogul's paper, Clarifying the Fundamentals of HTTP [1] defines the term instance for HTTP in a way that gave a basis for RFC3229 - Delta encoding in HTTP [2] d) The MIME specs don't give us very good terminology to describe what is allowed in places that allow MIME types. I think we should explicitly say that we mean a MIME type to be composed of a main type and subtype with no parameters. It wouldn't do any harm. e) Inheritance of things like atom:copyright and atom:author seems rather subtle. They appear to work in slightly different ways, and I'm not sure that the spec is clear enough on exactly how this inheritance is supposed to work. As Dan Brickley said recently, Atom's job [...] is to be clear about what the document means. I was planning to methodically enumerate some possible effects of inheritance, and to check whether the spec is ambiguous about any of these (it might all be fine). Eg: should an impeccably behaved Atom implementation treat these two the same (eg should a server record the two differently in its database): feed atom:entry atom:authoratom:nameDavid Powell/atom:name/atom:author [...] vs: feed atom:authoratom:nameDavid Powell/atom:name/atom:author atom:entry atom:authoratom:nameDavid Powell/atom:name/atom:author [...] Apart from that, I think things are pretty solid. [1] http://research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.pdf [2] http://www.ietf.org/rfc/rfc3229.txt -- Dave
Refresher on Updated/Modified
I'm engaged in trying to convince a large well-known organization to take Atom seriously (I think I'm winning) and we had this email exchange, which I thought might be useful as a refresher for those who have blissfully forgotten the great updated/modified debate. === I think the biggest concern right now is that that the LastUpdated date can be left unchanged even when the post IS changed (e.g. spelling corrections) What you want is reasonable to want but unfortunately no syndication format can give it to you. Here is the current language: The atom:updated element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. There was a proposal for an atom:modified date that was to be updated every time any change no matter how tiny was made but it was shouted down. There were many arguments against, but here are three that I couldn't think of an answer to: 1. The datestamp is inserted by the provider. Thus it could be a lie; this is the Internet, remember. You, the consumer, either trust the publisher or you don't. If you don't, you will ignore the datestamp and check the content. If you do, you will believe the datestamp. Thus, modified buys you nothing. 2. There's endless room for argument as to what constitutes an update: change in the stylesheet for background colors, change from a unicode combined char to single + combining diacritic, change in paragraph 27 of an article that doesn't show up in a summaries-only feed, change from UTF-8 to UTF-16 encoding, there were more examples too, some of them scary-subtle. 3. Several publishers on the list asserted that they needed the right to make trivial spelling-correction-level changes without having a zillion literal-minded feed-reading clients re-fetch the material, and that they would simply refuse to update an atom:modified date if they didn't feel like it. Objectively, the upstream information provider controls the datestamps. If you can think of a way to write a syndication format that will function across the Internet and reliably force providers to provide accurate modified indicators, there are a lot of people who would like to hear about it.
Re: Compulsory feed ID?
On May 19, 2005, at 12:36 PM, Robert Sayre wrote: On 5/19/05, Tim Bray [EMAIL PROTECTED] wrote: co-chair-mode (Text not provided, we trust the editors to figure out the correct way to say this). The editors request that text be provided. In section 4.1.1, change the bullet point that reads atom:feed elements MUST NOT contain more than one atom:id element. to read atom:feed elements MUST contain exactly one atom:id element. Plus, take the ? off the atomId in the RNC immediately above. Editorial oversight from anyone is welcome, I'm kind of tired. -Tim
Re: multiple ids
On May 19, 2005, at 12:43 PM, Robert Sayre wrote: --- The editors are directed to modify the phrase which starts If multiple atom:entry elements... as follows: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such. --- We don't use the word 'software' in the draft. The editors request replacement text. s/software/Atom Processors/ for consistency with the rest of the draft. -Tim
Re: Refresher on Updated/Modified
Tim, can I ask about your thinking regarding the use of atom:updated in PaceDuplicateIDs. What if someone (either the publisher or someone downstream) wants to store a history of every revision in an archive feed? atom:updates forces one to choose only one version per significant change. The mechanism it affords (being able to automatically display the newest version) is vital, but it doesn't seem like the best way to do it. Graham
Re: Non-empty elements
On May 19, 2005, at 12:40 PM, Robert Sayre wrote: co-chair-mode Paul and I consider that the following text has consensus support of the WG and the editors are directed to include it in the format draft (editorial judgment call on where to insert): Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. For that reason, it is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. /co-chair-mode Is this text intended to replace the paragraph the editors were previously directed to insert? Nope, can't do that, because there's stuff in that paragraph that's not here. Here's my best effort at combining the original consensus call with the above paragraph: Experience teaches that feeds which contain textual content are in general more useful than those which do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. However, the absence of atom:summary is not an error and Atom Processors MUST NOT fail to function correctly as a consequence of such an absence. -Tim
Re: Refresher on Updated/Modified
On May 20, 2005, at 5:07 PM, Graham wrote: Tim, can I ask about your thinking regarding the use of atom:updated in PaceDuplicateIDs. What if someone (either the publisher or someone downstream) wants to store a history of every revision in an archive feed? atom:updates forces one to choose only one version per significant change. The mechanism it affords (being able to automatically display the newest version) is vital, but it doesn't seem like the best way to do it. I don't see why, if you wanted that kind of archive, you couldn't use atom:updated for every little change in the archived version but atom:updated only for the ones you cared about in the published version. In which case the archived version would be a superset of the published version. I see nothing wrong with that. -Tim
Re: Refresher on Updated/Modified
[reposted without so many typos and grammatical errors - reply to either] As I was the last person to mention atom:modified, I'll refer to my proposal as an example in this reply. 1. The datestamp is inserted by the provider. Thus it could be a lie; this is the Internet, remember. You, the consumer, either trust the publisher or you don't. If you don't, you will ignore the datestamp and check the content. If you do, you will believe the datestamp. Thus, modified buys you nothing. The rationale for PaceDateModified2 was to enable multiple revisions of entries to exist in the same Atom Feed Document. This usage doesn't require trust relationships to be set up. Cross-feed duplicate detection is a useful feature that requires a web of trust to work reliably. Atom doesn't provide this natively, but future companion specifications could provide a framework, just as DomainKeys and other specifications are trying to do for SMTP. Hopefully Atom deployments will be a bit more agile than SMTP, so this wouldn't be such a slow process. 2. There's endless room for argument as to what constitutes an update: The text of PaceDateModified2 is looser than most of the previous proposals that were made, it is actually rather similar to the mandatory atom:modified element in Atom 0.3. It is updated when information in the entry (not the physical atom:entry element), which is reflected in the document is changed. Given that definition, I think that whether atom:modified needs to be updated can reasonably answered: change in the stylesheet for background colors No: On the web you don't update the Last-Modified date for a web page when a linked style-sheet has changed, nor would you update atom:modified when documents linked to an Atom entry change. It is implicit in any specifications which uses URIs to reference related documents, that the representations are subject to change over time. HTTP's extensive cache-control mechanisms deal with this. change from a unicode combined char to single + combining diacritic, No. change from UTF-8 to UTF-16 encoding No. change in paragraph 27 of an article that doesn't show up in a summaries-only feed, No. 3. Several publishers on the list asserted that they needed the right to make trivial spelling-correction-level changes without having a zillion literal-minded feed-reading clients re-fetch the material, and that they would simply refuse to update an atom:modified date if they didn't feel like it. Re-fetch? If they know that the atom:modified date has changed, then they already have the entry don't they? Do you mean that they want to discourage clients from re-fetching linked images etc? HTTP cache control mechanisms are the way to do this. Most aggregators defer image retrieval to a browser widget, so whether the document has changed or not will have no effect on whether the linked documents are refetched for these implementations. The Atom police wouldn't be able to stop people from ignoring the specification and faking atom:modified to a fixed value, but the effect for the subscriber would be similar to if a server operator faked Last-Modified to a fixed value in HTTP. The wide deployment of Atom 0.3 suggests that support for atom:modified wouldn't be an unsurmountable burden for implementations, but anyway, there is another alternative: I proposed PaceDateModified2 to address the issue that feeds containing multiple revisions of an entry would not be able to distinguish which revision is the latest. (Remember the entries are unordered). Some sort of atom:revision-count element would work too. Its value could even be defaulted to 0 in its absence for minimal intrusiveness. I think that atom:modified is a better option though, because it has uses beyond revision sorting within a document, and it is probably easiest for implementations to implement given the widespread support for a similar element shown in BlogToolDateSurvey. -- Dave
Re: Refresher on Updated/Modified
On 21 May 2005, at 2:15 am, Robert Sayre wrote: On 5/20/05, Graham [EMAIL PROTECTED] wrote: Say I'm aggregating feeds into a search results feed, and I get the same entry twice (with the same atom:id and atom:updated), from different sources. Would it be acceptable to me to adjust the atom:updated by one second and put both in the results, to show the end user the entry was available from two places? I think you are conflating timestamps and version identifiers. Just to be clear then, my example was meant to be of the sort of bad behavior PaceDuplicateIds encourages, not of something I'd want to do. It's the Pace that'd doing the conflating. Graham
