Re: Autodiscovery Draft
On 20/3/07 9:00 AM, John Panzer [EMAIL PROTECTED] wrote: Also, is there a standard way to discover the collection associated with a feed? (Given that, if there is an IETF or WHAT-WG way to discover feeds, there's an obvious way to discover collections... but I'm not clear on what that would be. I do think that collection autodisco is important.) please remember that there may be multiple collections collated into one feed ... and that various members of one collection may be represented in many different feeds. it's not 1:1. e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: * Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]: Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. That is, IMO, a misconception about Atom one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. wha? What music Lisa is listening to when she wrote a blog posting is meta data, not content, unless of course she's writing a blog posting *about* that particular bit of music. The music is contextual meta data, along the same vein as geo location of circumstance, the atom:generator involved, and even the atom:published date/time. Since when are we calling atom entries envelopes? e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 17/12/06 2:20 AM, Tim Bray [EMAIL PROTECTED] wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. Not sure exactly, but I did raise the possibility of a client passing in XML whose only purpose is for the benefit of other clients. Things like editorial comments and such. These would have been shepherded in the app:control element, and there was a great deal of discussion about the contents of app:control not being published (whatever that meant). It got hairy, and there wasn't much support for the idea. e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 15/12/06 7:29 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. promise? does the spec support this assertion? or is this another case of the server is in charge and can accept or change whatever it wants? e.
Re: Atom Entry Documents
On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote: application/atom+xml; type=entry application/atom+xml; type=feed I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream. For example. ones describing the expected extension model(s) of the target Atom document. Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be this is an Atom document containing OpenSearch results or this is an Atom Document that describes media using Media RSS extensions. I'm not so sure. I see the difference between the two being one vs many, and nothing more. What you want could however be accommodated by additional parameters.. I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul. One specific issue is that you will also have to deal with combinations (ex this Atom document is a feed that contains OpenSearch results listing Media RSS entries). application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS (or syntax to that effect) e.
Re: PaceEntryMediatype
On 11/12/06 2:26 PM, Joe Gregorio [EMAIL PROTECTED] wrote: Adding an optional parameter that indicated an entry or a feed would be a more elegant solution: application/atom+xml;type=entry application/atom+xml;type=feed I certainly agree it would be more elegant. A more pragmatic solution would be to go with application/atom.entry+xml ... if WHATWG don't update their spec, we're safe; if anyone has implemented per the current draft WHATWG spec, we're safe; if any implementations use naïve string matching, we're safe. The only danger is if someone has implemented APP per the moving target which is Draft-[n++] ... they should revise their test implementations as the draft updates, and certainly update once it reaches RFC status, so no sympathies there. e.
Re: PaceEntryMediatype
On 6/12/06 3:52 PM, James M Snell [EMAIL PROTECTED] wrote: Not necessarily. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. If an agent found an entry document, should it assume that it's a feed with one entry (so far) and allocate resources accordingly (ie. allow for cardinality of n++)? If an agent found an entry document, and then later returned to find a feed containing multiple entries, would it consider that a problem? Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. foo attr=1 attr=2 / ? e.
Re: PaceEntryMediatype
On 6/12/06 5:06 PM, James M Snell [EMAIL PROTECTED] wrote: Would an agent finding multiple atom:content elements inside the one entry consider that a problem (other than it being a spec violation)? Are XML processors optimised for the fact that any given attribute can only occur once per element, and not twice or more .. eg. foo attr=1 attr=2 / ? Ok, you lost me on these last two. I'm not sure what you're getting at. It's just the cardinality question in a different context. Argument by analogy. e.
Re: PaceEntryMediatype
On 1/12/06 5:21 AM, Antone Roundy [EMAIL PROTECTED] wrote: 5) Create a new media type for entry documents, and use @rel values to solve issues that doesn't solve: +/- Messy territory If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. Starting from scratch, idealised, I'd want different media types (or params) for entry documents and feed documents, and link type which clearly indicates this is for subscription, as distinct from this is an alternate representation, this is an archive, etc. Using the two mechanisms together allows combinations such as here is a feed you can subscribe to of the comments for this entry and here is a feed document listing related resources, but since it won't likely be updated don't bother subscribing. I'd like to be able to use a lot of the link types we currently use for html (directory, help, toc, related, next, etc) to refer to resources which happen to be serialised in the atom feed document format, and feel safe in knowing they won't be automagically treated as being subscription feeds. e.
Re: PaceEntryMediatype
On 30/11/06 5:39 AM, Henry Story [EMAIL PROTECTED] wrote: would that not be solvable by atom:link rel=entry type=application/atom+xml href=a.xml / not if you want to do this: atom:link rel=something-else type=application/atom+xml href=a.xml / where 'something-else' might be 'comments' or 'history' or 'unexpurgated' or 'disemvowelled' or many other as yet unknown opaque-strings, some of which would be used when linking to feed documents, some when linking to entry documents. e.
Re: PaceResurrectAutodiscovery
On 24/11/06 9:28 AM, Thomas Broyer [EMAIL PROTECTED] wrote: Being a syndication feed is expressed by the media type, there's no need for a 'rel' value. I disagree, but for slightly different reasons. Consider these two links: link rel=feed type=application/atom+xml;type=feed href=/latest.atom / link rel=alternate type=application/atom+xml;type=feed href=/2006/10.atom / They are both Atom Feed Documents, but the former is the syndication feed to which one would reasonably subscribe to for delivery of more content like you're looking at, and the latter is simply an alternate representation of the current content (in this case being an archive page for October 2006), and subscribing to it would be foolish. Also, how do we have syndication feeds in different representation formats (eg. RSS), or are you proposing the ;type=feed gets appended to all the various media types as needed? The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document; otherwise, the feed is just a syndication feed, not necessarily associated with a particular Web page. There's a third case they don't mention here, which is if 'alternate' is used but 'feed' is not also specified ... in which case it's not a feed in the sense of a source of continuing updates, but more like a static resource (subject to the usual bit rot and tweaky updates). The three cases are: @rel=feed @rel=alternate feed @rel=alternate Would be nice if there was an RFC we could point at which clarified what is meant by each. Would go a long way towards overcoming deployment inertia. e.
Re: AD Evaluation -- extensions
On 18/10/06 8:07 AM, Lisa Dusseault [EMAIL PROTECTED] wrote: Extensions When the client puts extension elements in a MER, MUST the server store those unrecognized extension elements? I think the answer to this is actually that servers often do not and should not be required to do so. That makes it hard for clients to extend AtomPub's syntax in ways that other clients will understand but servers don't care about. Consider the consequences: when some enterprising client developer decides to do something cool and useful and encounters servers that don't store their metadata in the obvious place, the client developer is going to quickly work around that by storing in some unobvious place. For example in HTML comments in the atom entry content, or microformats, etc. Is that all cool? This issue also has implications on what extensions are passed through to the published feed ... a client might insert some extension metadata they want published (eg. geo-coordinates), and a client might insert some extension metadata they only want visible within the collection feed (eg. editor workflow comments) ... with the understanding also that if the server actually understands a particular extension it might result in extensions being added/modified outside of the bucket (eg. ext:include trackbacks=yes / resulting in lots of link/ elements being added) We did at one time discuss providing a bucket container specifically for the latter, with the assumption that extensions outside the bucket are data elements meant for publication. Having a bucket container would make life simpler for server implementations -- just store everything as an xml blob, the same as they do for atom:[EMAIL PROTECTED] Lisa, would that help? e.
Re: Atom and bidi
On 3/10/06 11:44 AM, James M Snell [EMAIL PROTECTED] wrote: If the default direction for the entire document is RTL, allowing that to be established at the feed or entry element level can save some effort adding the appropriate controls to every text element. so @dir is to be inherited by contained elements (similar to how xml:lang and xml:base is)? what happens with content src=.. dir=rtl / ? e.
Re: Atom and bidi
On 4/10/06 1:03 AM, James M Snell [EMAIL PROTECTED] wrote: A dir=rtl on the content element establishes the base direction for the content but, just as with xml:lang, the content itself can override the value using whatever mechanisms are native to the content type. xml:lang doesn't go to a child (embedded) document. The language specified by xml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance of xml:lang. what happens here? a href=.. dir=rtl .. yadda .. /a e.
Re: Atom and bidi
On 4/10/06 3:44 AM, James M Snell [EMAIL PROTECTED] wrote: Either way, the behavior of the dir on the anchor is unmodified and standard (X)HTML rules apply. so how might you code this: phere is some ltr text, with a link with a href=..rtl-text/a which links to a document which is ltr-text/p I know the difference between @xml:lang and @hreflang ... so which is @dir analogous to? e.
Re: WG Last Call for draft-ietf-atompub-protocol
On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote: PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. There also seems to be universal support for the notion that collection feeds could be sorted by something other than what's currently in the spec. The spec currently not only says collections are to be sorted by atom:updated, but because of the MUST it also says it MUST NOT be sorted by anything *else*, which is a problem. Section 10.0 ¶ 2 says this: The entries in the returned Atom Feed MUST be ordered by their atom:updated property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the atom:updated value of an entry will not affect the position of the entry in a Collection. We need to either strike that entire paragraph, or at the very least make that MUST into a SHOULD. I say +1 to s/MUST/SHOULD/ e.
atom:updated - not now() values?
When updating an entry, is it acceptable to insert a value other than Now() into atom:updated? For example: Corporate Communications prep a release and they stamp it with a release date of Monday 4 PM ... but I don't see this release update until I get into the office at 2 PM Tuesday, and thus I quickly enter it into the CMS and set the atom:updated value to Monday 4 PM. e.
Re: Language Negotiation
This took me quite a while to think through, but in the end I agree. Translations of a resource will often have slightly different contents in terms of the semantics of what is said, so I'd give them different ids. what would happen if you used conneg on the @rel='self' link (to the entry/ document), asking for a different language? e.
Re: Language Negotiation
On 27/7/06 7:42 PM, Thomas Broyer [EMAIL PROTECTED] wrote: what would happen if you used conneg on the @rel='self' link (to the entry/ document), asking for a different language? You mean, sending an Accept-Language request-header? 406 Not Acceptable or return the entry even if it does not match the accepted languages. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7 so, do not return the requested language alternate? e.
Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt)
On 30/6/06 1:34 AM, Bill de hÓra [EMAIL PROTECTED] wrote: Which are clients supposed to respect in a conflict, the Content-Language header or the xml:lang, ie, does XML On The Web Failing Miserably, Utterly, And Completely extend to Content-Language+xml:lang? xml:lang, if you think of xml being nested. in other words, what is the lang of the atom:content below: HTTP 200 OK Content-Language: ch ... feed xml:lang=fr ... entry xml:lang=it content xml:lang=en ... ... /content ... /entry ... /feed e.
Re: Copyright, licensing, and feeds
On 10/6/06 12:02 AM, James M Snell [EMAIL PROTECTED] wrote: In the Feed License Draft, feed's a licensed independently of their contained entries. There is no interaction between the licenses. Ah, no inheritance. Makes sense really, since if that was in the spec it would fail for aggregators that are not aware of that inheritance. e.
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: You mean `hreflang`, not `xml:lang`, right? oops, yes. I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. :-)
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: entry link rel=replies thr:count=5 xml:lang=en href=1 / link rel=replies thr:count=1 xml:lang=fr href=1 / ... /entry You mean `hreflang`, not `xml:lang`, right? I also meant there to be different hrefs too :-( entry link rel=replies thr:count=5 hreflang=en href=1 / link rel=replies thr:count=1 hreflang=fr href=2 / ... /entry e.
Re: Feed Thread in Last Call
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e.
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. this should be amusing too: entry link rel=replies thr:count=5 href=1 title=trackbacks! / link rel=replies thr:count=1 href=2 title=comments! / ... /entry e.
Re: Tools that make use of previous/next/first/last links?
On 1/5/06 2:25 PM, James M Snell [EMAIL PROTECTED] wrote: While I'm sure the other James may have his own particular set of issues, the one pain point for me with the history spec is the use of the previous link to point back in time. This runs counter to the use of the previous link in both OpenSearch, APP and Gdata. I thought OpenSearch results are not sorted by chronological age at all, but instead by relevance? Using next with OpenSearch makes sense in that context. Using previous for stepping back thru time in a data store arranged chronologically makes sense. I'm not familiar with how Gdata arranges it's data, but briefly scanning the API docs it's modelled on OpenSearch, and furthermore it says Result ordering is up to the implementation ... thus I would think it would be right for it to use 'next' to get the next page, but wrong to assume that this would imply stepping backwards chronologically. e.
Re: Tools that make use of previous/next/first/last links?
On 1/5/06 5:55 PM, James M Snell [EMAIL PROTECTED] wrote: That said, however, we end up with a problem when we have one spec that says next points backwards in time (APP), one spec that says next points forwards in time (feed history) and one spec that says next is just another page of entries that match some criteria (opensearch). No matter what the various link types point to, there needs to be consistency. As it stands now, a single feed cannot implement APP, OpenSearch AND Feed History. I just reviewed the relevant example in the APP spec and it's worrisome. Reading between the lines it suggests that the subscription uri is http://example.org/entries/go;, with the rest of the collection available via rel=next through to http://example.org/entries/10;. The worrisome thing is that once that collection gains another 10 entries, then the resource http://example.org/entries/11; will now contain the entries which were previously contained by resource http://example.org/entries/10;. Every page of the collection needs to be updated and have the entries shuffled along. A simplified example: /entries/go contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D which then gets another 4 entries added (ie. U,V,W,X) and the collection now looks like this: /entries/go contains entries U,V,W,X /entries/1 contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D This is just smells bad in so many ways. Pity the blog package that publishes static files and will have to rebuild every collection page. Pity the poor server that gets asked if /entries/3 has been modified and if so hand it over. Pity the google bot that does all that asking. Of course, this sentence doesn't parse into English real well either: next and prev link elements reference the preceding and subsequent feed documents in the set. ie. next references the *preceding* feed document, and prev references the *subsequent* feed document. It doesn't even make sense when read Down Under ;-) e.
Re: Feed Thread Draft Updated
On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote: Where that gets nasty, of course, is when the href is relative and xml:base is being used to set the Base URI. Publisher would need to make sure that the href/ref combo match up properly Would this be considered a match? link rel=replies href=comments xml:base=/06/04/21/blah/ / thr:count ref=/06/04/21/blah/comments updated=...5/thr:count You just know there'll be a few idiots that will try that on. e.
Re: Feed Thread Draft Updated
On 13/4/06 8:02 AM, David Powell [EMAIL PROTECTED] wrote: In terms of the considerations to the interoperability of running code, thr:replies seems to beat atom:link in every way. It even manages to be more concise (you don't need the @rel), and you wouldn't need to put thr:count and thr:when into a namespace (namespaced attributes confuse people). atom:link beats thr:replies on the basis that I don't need to understand what replies are to discover that there is a link from this thing to that thing. atom processors know what atom:link is, but it wouldn't know what to do with this: xyz:qwerty foo=opaque-string bar=opaque-string qaz=opaque-string zak=opaque-string / e.
Re: Feed Thread Draft Updated
On 13/4/06 6:59 PM, David Powell [EMAIL PROTECTED] wrote: But what would processors do with an atom:link? Atom Protocol uses edit, there have been calls for a stylesheet. Links aren't necessarily things that you'd display to users (check HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL) as I understand it, dereferencing the 'edit' link returns a representation of the entry which is suitable for editing (ie. it contains all the bits needed). as to the other link types in html ... I hope we've learned something from that experience since then. e.
Re: Does xml:base apply to type=html content?
On 31/3/06 3:08 PM, Antone Roundy [EMAIL PROTECTED] wrote: The escaped HTML content contained within the content element that David was originally concerned with is more than likely a copy of all or part of the elements and content contained inside the body tag of the external document referenced by an associated link element, and therefore no guarentee that the xml:base of the atom feed is going to be anywhere even close to accurate. I'm doing something similar right now, scraping some website that doesn't provide feeds for what I want. I check the html of the page I scraped and if they have a base I use that, else I use the URL I used to fetch the page. The tag soup I extract for each entry contains relative references. I really don't want to go fixing that tag soup so I just stick that base url into xml:base for each entry (and not just at the top of the feed, because I'm scraping paginated results). e.
Re: atom:name ... text or html?
On 24/3/06 4:42 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I'm getting the data by scraping an html page, so I'm expecting it to be acceptable html code, including html entities. Then decode the entities to a Unicode string and emit the feed as Unicode. Simplest thing that will work reliably. I figured as much. Oh well, now to track down a list of html entities and their corresponding unicodes ... e.
Re: Atom syndication schema
On 15/3/06 2:21 PM, Martin Duerst [EMAIL PROTECTED] wrote: Not sure if this is a known bug, but I just noticed that the RelaxNG grammar doesn't accept atomCommonAttributes (eg xml:lang) on the atom:name and atom:uri and atom:email elements used within Person constructs. For atom:uri and atom:email at least, not having xml:lang may be seen as a feature. While these often contain pieces from one language or another, they are not really in a language. Since the original discussion I've stumbled across something extra that makes xml:lang relevant for atom:name. Seems that in writing Hungarian names, the pattern is always surname followed by forename - e.g. Bartók Béla, where Béla is the personal name and Bartók is the family name. While common western names (eg. Eric Scheid) would be indexed as Scheid, Eric; a comma is instead simply added between the Hungarian surname and forename, making Hungarian names indistinguishable from other Western-style names. For example: Bartók Béla is indexed as Bartók, Béla. Icelandic names are another game altogether. e.
Re: Browser behaviour
On 2/2/06 12:51 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Then again, I can¹t think of interesting information to put in the referrer of regular feed poll requests, but maybe my imagination is just too limited here. Who said the aggregator would be limited to only doing regular feed polls? My aggregator of choice lets me browse the links in entries, including any atom:links ... no reason it couldn't thus fetch a linked resource, and specify the current feed as the referrer. e.
Re: todo: add language encoding information
On 31/1/06 1:27 PM, James Holderness [EMAIL PROTECTED] wrote: Actually I was thinking just a regular href and type. For example: link type=application/atom+xml href=http://mydomain.com/feed; hreflang=fr x:id=french_entry_id x:updated=2005-11-15T18:30:02X / I'm not sure how valid that is considering a client that didn't understand this extension would consider the full feed to be an alternative for that one particular entry which doesn't seem right. Any reason that application/atom+xml document couldn't be an Atom Entry Document, apart from the current lack of reader/browser support? It could also then include the links necessary to subscribe to the specific language feed. e.
Re: Feed Thread Draft
On 26/1/06 4:23 PM, James M Snell [EMAIL PROTECTED] wrote: thr:in-reply-to id=tag:example.org,2006:/some/entry is that id for the thing being replied to, or the id of this thr:in-reply-to element? if the former, is suspect idref would be more appropriate. but what do I know? e.
Re: new draft? (was: invention)
On 22/1/06 3:27 AM, Robert Sayre [EMAIL PROTECTED] wrote: But, I could be in the minority. Which WG members think we should work on exciting new HTML link relations? Wow. Nobody. Phil, could we get a new rev of the Autodiscovery I-D? nobody likes a strawman. e.
Re: finishing autodiscovery, like now
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: But we already have a name for doing that: it¹s called ³linking to something.² Now, it¹d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? In fact, semantically, we should be encouraging people to move things out of their `link`s and into `a`s in the page. Sounds like PaceAnchorSupport. How do you propose we do this encouragement, if not by codifying it into a spec? On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote: The spec is extremely well-written and reflects existing behavior. The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. e.
Re: finishing autodiscovery, like now
On 20/1/06 7:52 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? this is an excellent point. How does either Pace address it? PaceDifferentRelValue addresses this. It suggests using feed as an @rel value to indicate the referenced resource is a feed (ie. is not an entry doc) which can be subscribed to. It doesn't rule out continuing to use alternate for those cases where the feed is actually an alternate to the current document. I am trying to think of a scenario where I¹d want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can¹t come up with anything. Can you provide an example? I'm not talking about autodiscovery of entry documents. I'm talking about autodiscovery of feeds, which (and this is the point) is *different* from autodiscovery of resources with the mime type of application/atom+xml. Apart from Atom Entry Documents, there are also application/ref+xml documents ... and not all of those are RSS 1.0 feeds. Using feed solves the problem for both cases (atom entry and rdf+xml), and potentially any similar problems (eg newsml+xml?). e.
Re: finishing autodiscovery, like now
On 20/1/06 7:57 AM, James M Snell [EMAIL PROTECTED] wrote: Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? This is a general limitation of the media type definition, not with the autodiscovery draft. We have the same problem differentiating atom:link type=application/atom+xml href=... /. This isn't a problem that the autodiscovery draft needs to solve. If it's a problem, solve it in the Atom format spec where the media type is defined. Too late. It would have been nice to have application/atomentry+xml Also, fixing it in the atom format spec doesn't fix the exact same problem autodiscovery has with application/rdf+xml. e.
Re: finishing autodiscovery, like now
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote: The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Unambiguous? The autodiscovery spec does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry documents. It only says that such links may be used to find Atom Feed Documents. This is a subtle nuance. e.
Re: finishing autodiscovery, like now
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: Okay, so you have two alternates: one with comments, one without. That would be `rel=alternate` in both cases, with `title=Entry` in one of them and `title=Entry with comments` in the other. This is semantically weak, I know. @rel contains tokens, @title contains human language content. Would @title=Entrada com comentários also be acceptable? How about @title=Entrata con le osservazioni or @title=Entrée avec des commentaires or @title=Entrada con comentarios or @title=Eintragung mit Anmerkungen? No. This is no basis for auto-whatever. No matter what the @lang might be, the @rel would still contain the same token for each of those possible @title links. It's just English Language Imperialism why it happens to be alternate entry, it could just as easily be specced to be FooBarBaz or 3576.24352.987. e.
Re: finishing autodiscovery, like now
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: And someone else still uses Atom in yet another clever way. Which is precisely why [EMAIL PROTECTED]alternate,@type=atom+xml] is an *ambiguous* way of discovering atom Feeds ... It¹s just impossible to specify enough precise semantics to cover everyone¹s use cases, and no single app will ever understand all of these disparate semantics. Strawman. I'm not suggesting we pre-define all these other cases. I'm suggesting we define this one case (here is a feed document related to this page) in a manner which distinguishes it from other [undefined] cases. The problem seems simple while you look at it with blog-coloured glasses because that is such a small and well-understood niche of the problem space. Be careful what you assume. I'm thinking of using atom entry documents for many non-blog related purposes, and this is what is driving my interest in disambiguating feed autodiscovery. e.
Re: finishing autodiscovery, like now
On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote: Why wouldn't this work? rel=alternate feed rel=alternate entry rel=alternate replies (see [1]) Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel I.e. the values are all orthogonal. Yes, but that would mean that it *would* work, not that it *wouldn't*. Being orthogonal means that those three links are equivalent to these six links rel=alternate href=1 rel=alternate href=2 rel=alternate href=3 rel=feed href=1 rel=entry href=2 rel=replies href=3 Which is exactly what was intended. e.
Re: finishing autodiscovery, like now
On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote: First person to need the feature has to spec alternate entry instead of making everyone change to alternate feed. How is speccing alternate entry helpful? That would *still* be considered an autodiscovery link to a feed, according the current autodiscovery spec. That's the problem right there. The spec should allow for the creation of other specs without land-grabbing the non-specific alternate @rel value. e.
Re: finishing autodiscovery, like now
On 20/1/06 12:32 PM, Joe Gregorio [EMAIL PROTECTED] wrote: On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote: Though at this point in this discussion, someone is always duty-bound to point out that the only use of link that HTML actually specifies, for stylesheets, treats them as not orthogonal (alternate stylesheet is not alternate and a stylesheet, it's an alternate-stylesheet), and further assigns meaning to the presence (though not, exactly, the content) of a title attribute. Marvelous. Yeah, awful. Are you suggesting we promulgate that behaviour in the face of autodiscovery for RSS that already uses alternate? Speaking for myself, quite the opposite. Robert Sayre is the only one so far suggesting that @rel=alternate entry should be treated as excluding the semantic of @rel=alternate. Which is surprising: I would have bet he would consider the alternate stylesheet thing an abomination. I'm suggesting that if we want to link to a resource which is considered to be a feed for the current document we use feed. If we want to link to a resource which is considered to be an alternate representation of the current document we use alternate. If the resource is considered to be both, then the x/html spec allows both relationships to be expressed in the one link as a space separated list. Specifying feed does not rule out using alternate feed for backwards incompatibility purposes, except to those implementations that can't cope with more than one value in @rel, and according to the autodisco 1.0 spec they are broken anyways so I have no compassion for them. e.
Re: finishing autodiscovery, like now
On 20/1/06 1:55 PM, Joe Gregorio [EMAIL PROTECTED] wrote: What autodiscovery links should I do on a web page that displays a single blog entry, like this one? http://journals.aol.com/panzerjohn/abstractioneer/entries/1238 Actually on my blog each page has a feed associated with it that is a feed of all the comments on that page. Are the comments on the same html page, or on another page? Some websites do it the latter way. It often depends on the size of the article, especially if the article is split into multiple pages (eg. http://www.xml.com/pub/a/2005/12/07/catching-up-with-the-atom-publishing-pr otocol.html ). In the first use case, it would make sense to have @rel=alternate feed replies (it's an alternate representation of the page, it's a feed of updates of this page, and it's a resource containing replies to this page). In the latter case however @rel=alternate feed replies would be broken. The replies are not on that page, so how is a feed of replies an alternative representation? It would make sense to have @rel=related feed replies though. Regardless, the current spec is unambiguous, it points to feeds. If we want it to point to something besides a feed it has to be changed. No, it does *not* point to feeds, it points to resources of a certain mime type of which a subset are feeds. There's the ambiguity. e.
Re: partial xml in atom:content ?
On 16/1/06 5:29 PM, Graham Parks [EMAIL PROTECTED] wrote: Except no one bothered to tell the aggregator writers they'd have to implement this, so no it's not safe. so atom is good for schlepping documents about, but not for elements of documents (with two exceptions) :-( e.
Re: partial xml in atom:content ?
On 17/1/06 2:21 AM, James Holderness [EMAIL PROTECTED] wrote: the media resource is supposed to be stored external to the collection feed and referenced via a content src link hmmm ... premature optimisation due to common use case of binary content? e.
partial xml in atom:content ?
Is this a valid atom entry? entry [...elided...] summarya snippet of foo xml/summary content type=application/foo+xml foo:thing xmlns:foo=http://xmlns.com/foo/0.1/; foo:nameKing George/foo:name /foo:Person /content /entry That is, is a partial xml document valid inside the atom:content element? What about xml formats whose specs state that there must be a certain root element (similar to how atom documents must have either feed or entry as root elements)? e.
Re: partial xml in atom:content ?
On 16/1/06 12:40 PM, Elliotte Harold [EMAIL PROTECTED] wrote: No. It's not even well-formed much less valid. ignore the typo. e.
Re: partial xml in atom:content ?
On 16/1/06 1:57 PM, James M Snell [EMAIL PROTECTED] wrote: entry ... entry type=whatever OPML's type is opml:outline xmlns:opml=whatever.. ... / /entry /entry Heh.. another typo methinks ;-) grrr! TooEarly - SufficientCoffee = Typos e.
Re: partial xml in atom:content ?
On 16/1/06 2:09 PM, James Holderness [EMAIL PROTECTED] wrote: The one time I'd think it might be safe is with XHTML (as I mentioned in a previous message) since Atom processors are already required to handle XHTML fragments in the content element. Anything else would be highly risky unless it was a proprietary feed communicating between two known applications. then you're not going to like what I was thinking of doing ... posting atom:category / chunks to an APP/media collection, such that the media collection entry might look like this (no typos this time, I hope)... entry ... content type=application/atom+xml category .../ /content /entry Thus, in the same sense I might have elsewhere a collection of images, I have here a collection of atom categories. I can hear the screaming already. e.
Re: partial xml in atom:content ?
On 16/1/06 3:46 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Thus, in the same sense I might have elsewhere a collection of images, I have here a collection of atom categories. That doesn¹t even work, because this is invalid: entry !-- ... -- content type=application/atom+xml category .../ category .../ category .../ /content /entry No, that isn't one entry in a collection of atom categories, that is one entry in a collection of *bundles* of atom categories. That's as wrong headed as trying to squeeze *three* images into the one atom media entry. If I have three categories in the collection, then they would be in three individual entries. An atom:content with an XML media type MUST have exactly one child element, so you can¹t do that. You need to wrap those categories in something. The manifest choice is atom:entry If I have a collection of atom:categories, the atomic unit is one atom:category. So having a collection where each entry has *one* atom:category in the atom:content element is what I would be trying to do. If I wanted to have a collection of _bundles_ of atom:categories, I'd probably need some foreign element to act as the bundling element (eg. foo:categories) Which just so happens to be a valid root element for `application/atom+xml`. Of course, you¹re pulling in an entire train of metadata elements at that point, which will probably be completely redundant, so whether that is any help I don¹t know. I don't want that train of metadata. I already have an atom:entry with which to carry metadata for that content. (Heh, I could even apply atom:categories to that content, same as any other content ;-) The last niggling concern is with atom-format: although atom:content can contain XML, can that be *any* XML data, or does the spec forbid atom+xml from there? What will the validator do? e.
Re: examples of merged feeds/feed aggregation?
On 21/12/05 3:53 PM, Michael Stillwell [EMAIL PROTECTED] wrote: Is the link rel=via href=a.xml element the right way to do this? the atom:source element is the right way. e.
Re: clarification needed: order of children of atom:entry
On 27/10/05 4:09 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: It would say descendents if it meant descendents, no? not if it was speaking in more general terms. e.
Re: Sponsored Links and other link extensions
On 25/10/05 4:59 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I am asking if is there a generic way for an application to implement alternate-link processing that gives sensible behaviour for any type of main link. link .. x:alternate ... /link couldn't get more generic than that. read it as: here is a link (ooh, look, some alternate href's!) If an implementor has to support alternative links explicitly for each type of main link, where¹s the difference to having specific relationships for alternative links depending on the main link type? good point. e.
Re: Sponsored Links and other link extensions
On 25/10/05 5:17 PM, Henry Story [EMAIL PROTECTED] wrote: link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link It¹s a lot more verbose and you have to fiddle with nesting. What do you get in return? ³It looks more XMLish²? yes!? We are using xml! not only that, but if someone wants to write another extension (gasp!), it would be very easy to fold it in, using native XML methods... link .. x:alternate y:attribute=.. ... z:extension .../ /s:alternate /link (not that I can think of any such extensions, but why be a bastard to future inventors and innovators?) e.
Re: Sponsored Links and other link extensions
On 25/10/05 5:06 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Is providing a @title an option that a lot of people would use and/or someone out there cannot do without? In Atom 1.0 not enough deployment to say In HTML ... *lots* of current practice of labelling mirrors with the org name and/or location. Lots. e.
Re: New Link Relations -- Ready to go?
On 24/10/05 5:31 PM, Thomas Broyer [EMAIL PROTECTED] wrote: This has not yet proven to be really needed (e.g. the Top 50 web site I saw didn't provide archives of previous rankings). When there'll be such a need, then we'll define a new link relation (I already proposed archives/history to link to a table of contents feed allowing navigation to e.g. snapshots of non-incremental feeds; another link relation for the webring use case if it proves to be needed one day). +1
Re: Sponsored Links and other link extensions
On 25/10/05 3:43 AM, James Holderness [EMAIL PROTECTED] wrote: My only suggestion would be using rel=enclosure on the inner links rather than alternate. There will be some Atom processors [1] that won't be able to tell the difference between an inner link and an outer link. and we're back to the duplicate bandwidth problem again :-( If you combine this with the requirement that an inner link with the same type and hreflang as the outer link must be bit-for-bit identical, we could cover the other use-case of multiple download sources. So far, no new elements or attributes necessary. what about the use case of alternate formats (etc) for the same resource? Not sure about the legality. not legal, since atom:link cannot appear there ie. while atom:link (the container) can contain foreign markup, atom:link (the embedded) is not foreign markup. e.
Re: Sponsored Links and other link extensions
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: You have to split on whitespace; that¹s much easier in my book than finding a nodeset of nested elements and iterating over it. I recall people screaming about micro-parsers before for a different attribute. Has anything changed? e.
Re: Sponsored Links and other link extensions
On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; xml:id=x-file / link rel=alternative-enclosure type=application/ogg href=http://example2.com/file.ogg; encl:alternative-to=x-file / -1 ... this is starting to get ugly. e.
Re: Sponsored Links and other link extensions
On 25/10/05 1:12 PM, James M Snell [EMAIL PROTECTED] wrote: +1 to Eric's -1. Let's keep it simple. link rel=... type=... href=... x:alternate type=... href=... title=... / /link I'm also liking it from another angle... With some of the other approaches dumb clients do harm to others, and while smart clients do no harm they don't get anything which dumb clients already get. With this approach dumb clients do no harm, and smart clients gain benefits not available to dumb clients. It sets up the right ecological pressures for the market to evolve in a way which is beneficial. So while let the market/implementations decide is often persuasive, we really should at the same time be asking what environment/ecology are we establishing for this evolution. e.
Re: Sponsored Links and other link extensions
On 25/10/05 8:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: If you want a concrete reason, it requires extra parsing whereas everything else would be automatically parsed by the XML library. You have to split on whitespace; that¹s much easier in my book than finding a nodeset of nested elements and iterating over it. There's another problem with this: @encl:mirrors=http://www2.example.com/file.mp3 http://www3.example.com/file.mp3; ... how do you attach @title to each URI, for example @title=Blah blah -- European Mirror. e.
Re: Sponsored Links and other link extensions
On 23/10/05 1:14 AM, James M Snell [EMAIL PROTECTED] wrote: The challenge with using alternate to point to files of different types is that why would someone do (a) when they can already do (b) without the help of a new extension (a) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; x:alternate type=application/ogg href=http://example2.com/file.ogg; / /link (b) link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3; / link rel=enclosure type=application/ogg href=http://example2.com/file.ogg; / With (b), how could you ever then provide multiple distinct enclosures for an entry. With (b) you're trying to say that the two sound files are the same thing, just different formats. For example, I might want to provide a movie file with commentary, and another movie file without commentary, and a third movie file showing just the special effects part in slow motion. They are not substitutes for each other. With (a), we know the .mp3 and the .ogg are simply different formats of the same thing. With (b) we don't know either way. What I want is a way of indicating that a particular resource is available at multiple locations. I'll use multiple link elements to indicate that there are multiple formats. And some aggregators will treat that as a basket of different enclosures and try downloading all of them. it would be fair to say that any two x:alternate with different @href's but equivalent x:md5 are mirrors. That can fit into the model with no other modifications :-) I would argue that the x:md5 for all alternates should be the same as the parent link. What about this though: entry xml:lang=en link href=1 rel=enclosure type=audio/mpeg x:md5=hash1 title=soundtrack x:alternate href=2 type=audio/mpeg x:md5=hash1/ x:alternate href=3 type=audio/mpeg x:md5=hash1/ x:alternate href=4 type=audio/mpeg x:md5=hash1/ x:alternate href=5 type=application/ogg x:md5=hash2/ x:alternate href=6 type=application/ogg x:md5=hash2/ x:alternate href=7 type=application/ogg x:md5=hash2/ x:alternate href=8 type=audio/wav/ /link link href=9 rel=enclosure type=audio/mpeg title=commentary x:alternate href=10 type=audio/mpeg hreflang=pt/ /link /entry Here we have an entry with two enclosures. The first enclosure is the soundtrack, and is available in mp3 from one primary URI and three mirrors, and also available in .ogg from three mirrors, and for the truly desperate also available as a .wav file. The second enclosure is a commentary sound track, but not available in any other formats or from any other mirrors, but there is a Portuguese translation variant if you (really) want. e.
Re: New Link Relations -- Ready to go?
On 22/10/05 1:33 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: First, rel=self is going to be implemented by most everything that groks Atom 1.0 in order to support one-click subscription, if applicable, right? Whereas this new relationship might not find such wide-spread support. I believe we're in a moment of grace right now and we could, with a bit of public advocacy, get 'subscribe' established and supported for one-click subscription. For these two (similar) reasons I think it might be wise to keep rel=self in the role that this new rel=subscribe thing is supposed to fulfill, and invent a new relationship that can point to the canonical location of the archive feed document. This occurred to me too, but I had my reservations about it. http://www.imc.org/atom-syntax/mail-archive/msg17284.html where I wrote: Fortunately, the link relation 'self' was defined in such a woolly way we could get away with re-purposing it. A few articles here or there, a bit of blog chatter, and the arrival of the fabled Developers Guide and we'd be set. I'd think this would be favourable to having to come up with a different pair of relations, like 'self' = what you subscribe to, may not look anything like the chunk in front of you 'this-chunk' = link to what you are looking at, not to be confused with 'self' e.
Re: Application for addition to Atom Registry of Link Relations
On 22/10/05 4:48 AM, James M Snell [EMAIL PROTECTED] wrote: Note the caveat, with the same combination of type and hreflang attribute values. The idea is to prevent a single license from being appearing more than once. Multiple license link relations MAY be used to indicate that the informational content has been published under multiple copright licenses. In such instances, each of the linked licenses is considered to be mutually exclusive of the others. but the second bit of text suggests that the following is allowable: link rel=license href=pay-me-for-commercial-use / link rel=license href=barter-for-commercial-use / link rel=license href=free-for-non-commercial-use / which is a situation which should be allowable (IMHO), and so the restriction should be removed: o atom:entry, atom:feed and atom:source elements MUST NOT contain more than one 'license' link relation with the same combination of type and hreflang attribute values. e.
Re: New Link Relations -- Ready to go?
+1 to all
Re: Feed History / Protocol overlap
Ok, somehow this slipped under the radar on me during my first reading. -1, as I prefer next, as in, the *next* document in a chain of documents. No matter which direction you head in, no matter which way the chain is sorted, the next document is always next, so that's not a useful distinction IMHO. You said that to me about next and previous for app:collection when I requested the value 'next' be changed to 'previous' to be consistent with the notion of elements existing earlier in time. What's different here? Nothing. I should have been more clear back then that I was +1 on 'previous'... my point was directed at Joe (not you), and that his line of argument (in favour of 'next') was not persuasive and so if he wanted 'next' then he'd better try another line of argument. As then as now, I'm still +1 on 'previous' for going backwards. e.
Re: New Link Relations? [was: Feed History -04]
On 18/10/05 3:32 PM, Mark Nottingham [EMAIL PROTECTED] wrote: Such agents should also take care to detect circular references between feeds when following them. s/between feeds when/between feed documents/ otherwise +1 e.
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
On 18/10/05 6:14 PM, Thomas Broyer [EMAIL PROTECTED] wrote: Yes, and navigating through the historical states of the feed resource is not paging, it's more like having access to archives. I was thinking about proposing yet another link relation archives: in the general use case, it would reference another feed document where each entry describes an archive: The word 'archives' is too general though. May I suggest @rel=history instead? Otherwise, +1 e.
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
On 18/10/05 5:51 PM, Thomas Broyer [EMAIL PROTECTED] wrote: How can there be more than one paging semantic applied to a single feed? If a feed (not feed document) is a set of entries (sorted by whatever metadata: updated, priority, relevance, etc.) and you publish chunks as many feed documents, paging is navigation from one to the other, following the sort order. ... and the subset of entries which are on page 1 sorted by one axis would be very unlikely to be on page 1 when sorted by some other axis. d'oh! If you want to provide the exact same entries sorted (thus paged) differently, then that's another feed. unless of course each feed document contains only one entry each ;-) e.
Re: Feed History / Protocol overlap
On 19/10/05 5:38 AM, Robert Sayre [EMAIL PROTECTED] wrote: I already have code that uses next for this. Why do we want to change it? Why did you choose next? e.
Re: Feed History / Protocol overlap
On 19/10/05 9:13 AM, Robert Sayre [EMAIL PROTECTED] wrote: rel: next definition: A URI that points to the next feed in a series of feeds. For example, in a reverse-choronological series of feeds, the 'next' URI would point deeper into the past. How will your code cope with a forward-chronological series of feeds? e.
Re: Feed History -04
On 17/10/05 9:30 PM, Lindsley Brett-ABL001 [EMAIL PROTECTED] wrote: I would like to toss out another thought - since the updated time of a feed is required, maybe it can be used to help determine the feed order/history. For example, if following a next link (or pick your favorite term), if the updated time gets older, then the client can understand these entries are from an earlier time. If when following the next link the updated time stays the same, then the client can assume this is just more of the same collection from the previous point in time (unordered collection). Just a thought... Won't work -- older date-paged archives may have an entry updated anytime in the future, and thus not only does that entry get a more recent atom:updated than any entries intervening then and now, but the feed itself will also get a more recent atom:updated. e.
Re: Feed History -04
On 18/10/05 12:43 AM, James Holderness [EMAIL PROTECTED] wrote: Eric Scheid wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML. I'm still not exactly sure which of the two options you're in favour of. This is the reason why the point is being debated - it's not immediately obvious which way is most consistent with usage elsewhere. Nottingham or Pilgrim? hmmm ... I did say Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML... Chapter #1 comes first, followed by chapter #2, and you go from chapter #1 through to chapter #nnn via 'next'. Think too of Pepys' Diary. What would you consider the 'first' entry? Would the 'first' entry be 1st January 1660, or would it be 16th October 1662? Note well though that sometime tomorrow the latter point would be neither 'first' or 'last' because there would be a new entry for the 17th October 1662 (and yet another one the day after). 2. Are next and prev both needed in the spec if we only require one of them to reconstruct the full history? Knowing that the most recently published archive won't likely remain the most recently published archive, there will be use cases where it's better to reconstruct the full history by starting at the one end which is fixed. Not much sense starting at the other end which is constandly shifting. The way I understand it, both sides are fixed as soon as there is at least one archive. At the one end you have the oldest archive. At the other end you have the current syndication document (to which the end-user would subscribe). Both URIs are fixed. What I mean by fixed is that it doesn't move or change as the set grows. Adding one onto the end and resetting where 'last' points to means that 'last' is *not* fixed. What you mean is that as soon as there is at least one archive then both ends are *established*. One end is fixed, and the other will grow. 5. Is the issue of whether a feed is incremental or not (the fh:incremental element) relevant to this proposal? non-incremental feeds wouldn't be paged, by definition, would they? This has been debated. There have been those who have expressed an interest in having next and prev links traverse an archive of old non-incremental feeds. Say you have a feed with the top 10 books for this month. The next link (or prev link, depending on your preference) would point to the archive document with the top 10 books from last month. That makes sense. Personally I think that is an issue that should be argued and subsequently specified in a separate proposal on the use of non-incremental feeds. Just make sure the history spec is open enough to allow for either possibility once it is decided. I agree. So .. the issue of (not-)incremental is orthogonal to feed history then. e.
Re: Feed History -04
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: I'd prefer that our use of 'prev' and 'next' be consistent with other uses elsewhere, where 'next' traverses from the current position to the one that *follows*, whether in time or logical order. Consider the use of 'first/next/prev/last' with chapters or sections rendered in HTML. ...so do you follow forward through time or backward? Is the starting current position now or the the beginning of time? Especially if we're talking about history, following backward makes as much sense as following forward. You can start wherever you want, but the @rel='first' archive is the archive which contains the first entry that ever existed. Why would the @rel='first' archive contain the last entry created, that makes no sense. If you want to go backwards in time, then the next archive would be found by following the @rel='prev' link .. because you are going backwards! I prefer next to go back in time (if temporally ordered--from the most current chunk to the next most current chunk) or to less significant pages (in things like search results). But I'll probably have to stop and think what next means in temporally ordered feeds from time to time since it'd be the reverse of temporal order. You're also likely to get confused when comparing Atom archives against their HTML versions ... because in the HTML world the '@rel=first' page is conventionally the oldest page, and the @rel='next' page traverses forward in time. But what's first? It'd be the top results in a search feed, but would it be the start of time or the start from the present (before possibly travelling backward through time) in a temporally ordered feed? Making it the start of time would prevent it from matching up well with how significance ordered feeds match up (ie. does start point to the thing you'd most likely want to see if you subscribed to the feed?) If we're not careful, we'll be traversing out of first through prev and last through next! Ask yourself these questions: which is the first message in this thread, and if you wanted to understand the thread would you start there, or at the most recent entry in this thread and read backwards. Remember that by the time you've read back to the initial posting there would likely now be even more entries into this thread, so where would you then read them from ... where you started and going forward in time, or would you jump to the most recent and then read backwards until you hit a message you already read? So, would you read the messages in this order: 7,6,5,4,3,2,1,8,9,10,11,12,13,14 or... 7,6,5,4,3,2,1,11,10,9,8,13,12,14 or... 1,2,3,4,5,6,7,8,9,10,11,12,13,14 I know which way I'd prefer to read stuff. e.
Re: Feed History -04
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: Can self be polymorphic--the subscription URI in the live end of a feed, and this chunk in a historical chunk? Can an extension speak authoritatively about the meaning of something from the core spec? If it were so, and you were looking at an historical chunk, you would still need some link to where you might subscribe to that feed. So, if polymorphic, you'd have in the current living chunk a link of 'self' to subscribe to, but in a historical chunk you'd need to ignore the 'self' link and follow the 'subscribe' link instead. If not polymorphic, in the current living chunk you'd have a 'subscribe' link, and in a historical chunk you'd have a 'subscribe' link. They would both mean the same thing, and have the same value. In the historical chunk the 'self' link would be different from the 'subscribe' link (pointing at the historical chunk, of course), but in the current living chunk they could very well have the same value ... or not... The or not case is best exemplified by the nature.com feed links. If you want to subscribe to Nature Medicine, you'd use this URI ... http://www.nature.com/nm/current_issue/rss/ ... but if you were to attempt to retrieve that URI today you would find yourself redirected to ... http://www.nature.com/nm/journal/v11/n10/rss.rdf ... where, if were atom, you might find a 'self' link pointing to that second URI, not the first. The nature.com feeds are, btw, a rather good real-life example of non-incremental feeds. e.
Re: Feed History -04
On 18/10/05 2:04 AM, Antone Roundy [EMAIL PROTECTED] wrote: 2) Search results, where the order of everything all along the entire chain shifts around all the time. BTW, case 2 destroys the idea of a fixed end and a live end. Case 2 would be a closed set, generally speaking. geeking Technically, they wouldn't necessarily be closed sets. Tim Bray, search god that he is, has explained in some blog post somewhere that the smart thing to do is simply find the first hundred or so results, sort them, and only when the user asks for more pages to bother going off and finding more results to add to the collection. It's complicated, I think I understood it for all of 10 seconds after I finished reading it, and it only really applies to searching massive collections ... searches in more finite collections would be, could be, completely closed sets. /geeking e.
Re: Feed History -04
On 18/10/05 4:39 AM, James Holderness [EMAIL PROTECTED] wrote: Eric Scheid wrote: Ask yourself these questions: which is the first message in this thread, and if you wanted to understand the thread would you start there, or at the most recent entry in this thread and read backwards. Remember that by the time you've read back to the initial posting there would likely now be even more entries into this thread, so where would you then read them from ... where you started and going forward in time, or would you jump to the most recent and then read backwards until you hit a message you already read? This makes perfect sense if you're a human reading messages, but now try and understand it from the point of view of a computer program (an Atom processor). The computer doesn't care which messages came first. Yes, the _computer_ does *not* care. So why should it's preference trump the human reader? I imagine a future where a client application would offer up feed documents rendered all pretty, and offer up any links to other feed documents as links the client application will itslef render rather than passing them to a HTML browser. Thus, a Feed Browser in the same sense as a HTML Browser. Do you want to explain to future users why the next link gives them last weeks news instead of next weeks news? It's not going to try and read the messages and make sense of them. It just wants to retrieve all the documents in the most efficient way possible. Do things efficiently then. Remember though that the computer does *not* care if the token is 'next' or 'prev' or even 'foobar'. Does *not* care. First off is has to start with the most recent document since that's what the user is going to subscribe to. From there, the most sensible thing to do would be to keep following links back in time to older and older archives until it has retrieved all of them or (if this is a feed that has been downloaded before) until it reaches an archive that it has previously retrieved. Did you say back in time? Your explanation is riddled with references to going backwards .. the aggregator/developer frame of reference is going backwards, so of course the next object would be the one marked as being prior to the one your are currently on. That is, the next feed to process is the one marked @rel='prev'. Depending on what meta-data is available, and which axis you wish to traverse, and in which direction, then the link to the object you wish to retrieve after processing the current one could be next, prev, hotter, colder, or foobar. The usage of the word next in describing the sequence of actions is entirely dependent on the purpose of those actions, and quite possibly completely detached from the meaning of the content being processed. The @rel='next' and @rel='prev' links however are part and parcel of the content. They describe the content. They are provided by the content publisher. They don't describe some third party's desired course of action. I don't dispute that you have valid reason for thinking that forwards in time is the way to go, but please don't assume those of us that think the opposite are necessarily insane. But that would take all the fun out of things ;-) e.
Re: New Link Relations? [was: Feed History -04]
On 18/10/05 9:53 AM, Mark Nottingham [EMAIL PROTECTED] wrote: So what happens when you need the rel=self (as currently defined) of an archive feed? The current definition being ... The value self signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element. thus a link with @rel='self' in the feed element would link to that archive feed document. Similarly, a link with @rel='self' in the entry element would link to a resource document of that particular entry. Thus (in context of feed) 'self' = identifies a resource equivalent to this feed 'subscribe' = identifies the resource to subscribe to The same holds true for archive feeds and the current sliding window chunk, which makes life easier. e.
Re: Feed History -04
On 15/10/05 8:28 AM, Henry Story [EMAIL PROTECTED] wrote: Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) My thinking is that of the two ends, 'first' and 'last', it would normally be the 'first' end that is anchored, while the 'last' end would shift as more is added. e.
Re: more than one content element?
On 12/10/05 7:54 PM, Pascal Philippe [EMAIL PROTECTED] wrote: I would like to try to understand why we can't have more than one atom:content element within an atom:entry element. Could you give me the reason of this choice? IIRC, it was thought it would be too burdensome for developers to cope with the possibility, first detecting that there are multiple atom:content elements, and then having to either choose one of the formats they support or providing mechanisms for the user to select. It would have been handy for a recent use case: in Switzerland, govt announcements need to be made in three languages, simultaneously, and without favour to any one language. e.
Re: Feed History -04
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote: Excellent. If this works out, there is an opportunity to merge the paging behavior of Feed History, OpenSearch and APP collections into a single set of paging link relations (next/previous/first/last). 'first' or 'start'? Do we need to define what 'first' means though? I recall a dissenting opinion on the wiki that the 'first' entry could be at either end of the list, which could surprise some. e.
Re: Feed History -04
On 14/10/05 2:01 PM, Joe Gregorio [EMAIL PROTECTED] wrote: Eric, It's like deja-vu all over again. http://bitworking.org/news/Atom_Auto_Sub_How_To :) I'd forgotten about that, I was only remembering the wiki. I still think it odd that one could traverse both prev and next from the start. In the context of paging link relations (first/next/prev/last) I would've thought that 'first' and 'last' are boundaries, and only the 'last' boundary would shift over time as more is added. e.
Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)
On 10/10/05 2:02 PM, James M Snell [EMAIL PROTECTED] wrote: * dcterms:valid has slightly more functionality in that you get to specify a start date. I don't necessarily want more functionality. The atom:updated date gives us a perfectly good start date. Perhaps atom:published would be better for this semantic. Unlike atom:updated, it can be hold a future value, IIRC. e.
Re: ACE - Atom Common Extensions Namespace
On 2/10/05 3:54 PM, James M Snell [EMAIL PROTECTED] wrote: As I've been going through the effort of defining a number of Atom extensions, I've consistently come back to the thought that it would be interesting to explore the creation of a Common Extensions Namespace under which multiple standardized extensions can be grouped. I've written an initial draft of the concept but before I submit it as an Internet Draft, I'd like to get some feedback from the group. Please review the attached and let me know what you think. Do you want to start it off as an empty container, or might it be strategic to submit it with a number of extensions mentioned by reference. If the latter, it would serve a bootstrapping purpose for developers new to Atom. A bit like that page for RSS which enumerates a collection of extensions. What about mustIgnore/mustUnderstand? An extension sharing the ACE ns can't require mU, right? e.
Re: FYI: Updated Index draft
On 21/9/05 1:05 PM, James M Snell [EMAIL PROTECTED] wrote: The ranking is part of the entry metadata. If an entry falls off the feed, there is no effect on the ranking metadata. With partial feed retrieval, ordering could be performed over the entire set of entries. How does this help (eg) bbc.co.uk order their news items in some sensible manner? Today, they have a couple of important stories, they indicate those entries are rank #1, #2. Tomorrow, they have more news, but not more important than yesterday's big news. The day after they have a new big story, it should be rank #1. The #1 and #2 stories from two days ago have fallen off the bottom of the feed. The only way out of this conundrum is that bbc.co.uk will have to update the original #1 and #2 stories and re-rank them as much lower. If they re-rank them as #46 and #47 then they will need to re-rank any previous entry at those ranks to lower positions, and similarly for any other entries with ranks which get pushed down. Eventually the entire history of the feed needs to be re-ranked. Unless entries can be marked as having no rank. Can they? e.
Re: FYI: Updated Index draft
On 21/9/05 9:35 PM, James Holderness [EMAIL PROTECTED] wrote: Marking entries as having no rank sounds like a nice idea, but I don't think it's feasible in the long run. thinking more ... I think the way to handle this is that the client application could weight the ranking with the age of the item, and thus a rank#1 item would appear near the top of the list, and then slowly drop away. You also get to know what the original ranking for an item is. e.
Re: FYI: Updated Index draft
On 21/9/05 5:18 AM, James M Snell [EMAIL PROTECTED] wrote: For instance feed entry ... i:rank10/i:rank /entry entry ... i:rank5/i:rank /entry /feed What happens when entries fall off the bottom ... do their rankings expire? How does that work with the diff+Feed method of partial feed retrieval? e.
Arr! Avast me hearties!
Tis be gettin' t' th' time o' year when pirates be stalking th' deck. Arrr! (I can't keep that up...) there's a serious point ... I've just had the dubious pleasure of seeing a couple of subscriptions have all their entries marked as changed/unread, and on inspection I see they've flipped the magic switch and all their content is now appearing in Pirate Speak (via the magic of output filters, and barrels of rum). This includes messages posted before official pirate day. Sometime in the near future I expect they'll sober up, see the day has passed, and unflip the magic Pirate Speak switch. And all the subscriptions will again be presented in teh orginal spellig wonder. So ... ObAtom ... would recommended practice be to emit the garbled enunciations inline, with no change to atom:updated, and if there is any version tracking or modified dates present to also not update those? Make it look like some blurred illusion, fading from reality like a bad dream the next day faster than our rum soaked hangovers? e.
Re: FYI: Updated Index draft
On 15/9/05 6:06 AM, David Powell [EMAIL PROTECTED] wrote: Eg - An Atom library or server that doesn't know about this extension is free to not preserve the entry order, and yet to retain the fi:ordered / element, even though this will have corrupted the data. very good point. e.
Re: Structured Publishing -- Joe Reger shows the way...
On 12/9/05 9:00 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: * Henry Story [EMAIL PROTECTED] [2005-09-12 00:05]: In the DOAP over Atom type solution where the RDF is placed inside the content, there is then no more space to put the entry content itself. So I can either put the text entry into the content or the metadata. Where should the metadata go? Hmm. I think it¹s not metadata that we¹re talking about here, it¹s data. The location etc aren¹t a description of your weblog entry, they¹re a description of a place. So is your article. In other words, your article is ³meta²data about the cool bar. So it goes inside the RDF that is the entry¹s content. I was thinking the opposite. The article goes into content as text/xhtml, and the RDF goes into the entry as extensions. Now, that¹s not going to be accessible to clients who don¹t know look in the right place in the graph. Again, all the RDF extensions won't be accessible to clients that don't know where to look, but the article content will be available, because it's one of the baseline formats. So you put a copy of the article in your atom:summary, because it summarizes the full thing available in the RDF payload. Not if it's a long article, please. e.
Re: Question regarding specification 4.1.1
On 7/9/05 11:09 PM, Roland Jungwirth [EMAIL PROTECTED] wrote: When going through the Atom specification regarding syntax (http://ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt), I came to point 4.1.1 The atom:feed Element. This states that every atom:feed element has to have one (and only one) atom:id element but can have 0:n atom:entry elements. The atom:id element as an *immediate* child of atom:feed is the ID for the feed, while the atom:id element found as children of atom:entry elements are the ID's of their respective atom:entry. Completely different things. If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, they represent the same entry. Consider this (abbreviated) example: feed idsome-id-for-the-feed/id ... entry idid-for-entry-1/id ... /entry entry idid-for-entry-2/id updated2005-09-06T01:00:00Z/updated ... /entry entry idid-for-entry-2/id updated2005-09-06T01:05:00Z/updated ... /entry /feed This feed contains three atom:entry elements, two of which are actually separate representations of the same source entry, one at 1.00 AM, and one from five minutes later. In practice you probably won't see a mix like the above. e.
Re: Top 10 and other lists should be entries, not feeds.
On 31/8/05 7:50 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Is not logical order, if any, determined by the datetime of the published (or updated) element? No. I've seen a few things online where they publish chapter 3 first, followed by chapter 8, and then go back and fill in the blanks. And then update chapter 2. Sometimes there are good reasons for this, strangely enough. Leaving aside completely the idea of publishing a chunk, followed by more chunks, and *then* re-arranging them into some semblance of logical order once they know what content they have. e.
Re: Top 10 and other lists should be entries, not feeds.
On 31/8/05 6:01 AM, Mark Nottingham [EMAIL PROTECTED] wrote: It sounds like you've got use cases for Atom that other use cases (e.g., lists) make difficult to work with. Banning those other use cases makes things easier for you, but I don't think it's good for Atom overall. those other use cases are also a good example of some feeds which shouldn't be devoured by robots. e.
Re: Don't Aggregrate Me
On 30/8/05 11:19 AM, James M Snell [EMAIL PROTECTED] wrote: link rel=enclosure href=http://www.example.com/enclosure.mp3; x:follow=no / link rel=enclosure href=http://www.example.com/enclosure.mp3; x:follow=yes / content src=http://www.example.com/enclosure.mp3; x:follow=no / content src=http://www.example.com/enclosure.mp3; x:follow=yes / Why not an XML version of the HTML robots META tags - so we can also specify NOINDEX, NOARCHIVE as well as NOFOLLOW? Someone wrote up A Robots Processing Instruction for XML Documents http://atrus.org/writings/technical/robots_pi/spec-199912__/ That's a PI though, and I have no idea how well supported they are. I'd prefer a namespaced XML vocabulary. e.
Re: Don't Aggregrate Me
On 30/8/05 12:05 PM, James M Snell [EMAIL PROTECTED] wrote: That's kinda where I was going with x:follow=no|yes. An x:archive=no|yes would also make some sense but could also be handled with HTTP caching (e.g. set the referenced content to expire immediately). x:index=no|yes doesn't seem to make a lot of sense in this case. x:follow=no|yes seems to me to be the only one that makes a lot of sense. x:index could be used to prevent purely ephemeral dross cluttering up the uber-aggregators. A feed which gives minute by minute weather data for example. robots NOARCHIVE is used by search engines, particularly google, to control whether they present a 'cached' page, which seems sensible. e.
Re: Don't Aggregrate Me
On 26/8/05 3:55 PM, Bob Wyman [EMAIL PROTECTED] wrote: Remember, PubSub never does anything that a desktop client doesn't do. Periodic re-fetching is a robotic behaviour, common to both desktop aggregators and server based aggregators. Robots.txt was established to minimise harm caused by automatic behaviour, whether by excluding non-idempotent URL, avoiding tarpits of endless dynamic links, and such forth. While true that each of these scenarios involve crawling new links, the base principle at stake is to prevent harm caused by automatic or robotic behaviour. That can include extremely frequent periodic re-fetching, a scenario which didn't really exist when robots.txt was first put together. e.
