Re: Comments Draft
On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-07-30 01:40]: It's really just a hint as to where original entries MIGHT be found. “originally-at?” source? Graham
atom buttons
Hi, what are y'all using for Atom buttons? cheers Bill
Re: Atom Index Extension Proposal
James M Snell [EMAIL PROTECTED] wrote: FYI: http://www.snellspace.com/wp/?p=193 Abstract: Proposes two new elements that allow entries to be ordered within a feed. [xml condensed:] feed xmlns=http://www.w3.org/2005/Atom; xmlns:o=http://www.snellspace.com/atom/extensions/proposed; ... o:indexed / entry ... o:index1/o:index/entry entry ... o:index2/o:index/entry entry ... o:index3/o:index/entry /feed Certainly a very interesting idea. Having implemented openSearch [1] in my product feeds [2], I'd probably implement this, because it makes sense and would be very easy to do. My feeds are actually ordered (and paged) already, either by onsale date or by top seller, even though there's no way to indicate this in the XML. [Actually, it *should* already be in openSearch since that implicitly expects the feed entries to be ordered corresponding to the feed-level openSearch:totalResults and openSearch:startIndex elements.] Just my 2c. Regards, Peter [1] http://opensearch.a9.com/spec/opensearchrss/1.0/ [2] http://www.ticketswitch.com/cgi-bin/atom_feed.exe?page_no=2 (or http://www.ticketswitch.com/cgi-bin/rss_feed.exe?page_no=2)
Re: Comments Draft
* James M Snell [EMAIL PROTECTED] [2005-07-30 18:10]: Yeah, source is likely the most logical choice, but I didn't want to confuse folks with a link @rel=source that has a different meaning from atom:source. An argument by way of which I came around to Antone’s suggested “start-of-thread,” though I was going to suggest “thread-start.” But then I thought, we already use mail header lingo with “in-reply-to;” why not borrow another term from there and call it “references?” Yes, I know it’s not the same as the References: header. But the ultimate purpose (to trace the thread in newsreaders) is kind of similar, and more importantly, the term seems to fit the sort of relationship we’re trying to describe quite closely. If this is deemed a poor choice, then I fall back to “thread-start.” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: atom buttons
* Bill de hÓra [EMAIL PROTECTED] [2005-07-30 18:40]: what are y'all using for Atom buttons? I’m not using one, but I thought there was one with the atom from the Atom logo? I can’t find any such thing now, though; well, except the one at the feedvalidator, but that’s too large for my taste. Isn’t there a vector version of the logo available somewhere? This is something that always irks me; most people post their logos only as bitmaps, so it’s impossible to use them with page background colours other than the ones they provided for, or to scale the logo sanely, or make a smaller text-less logo from a button, or such. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Comments Draft
On Saturday, July 30, 2005, at 02:38 PM, A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-07-30 18:10]: Yeah, source is likely the most logical choice, but I didn't want to confuse folks with a link @rel=source that has a different meaning from atom:source. An argument by way of which I came around to Antone’s suggested “start-of-thread,” though I was going to suggest “thread-start.” I took a look at the draft to verify whether I correctly understood what this link points to, and I think it isn't what I originally thought based on the old name root. Does this point to the feed in which the immediate parent entry was found, or to the feed in which the first entry in a thread of replies was found? If the former, which the draft seems to suggest, and which seems more useful, then start-of-thread and thread-start probably aren't such good names after all. With clarity in mind, in-reply-to-feed might be good, though it's a bit long. And problem comes to mind: if you have multiple in-reply-to links, how do you related those to their respective in-reply-to-feed links (in case they're different)? Is it possible? Dare we do something like this? (Wish we to if we dare?) link rel=in-reply-to ... link rel=in-reply-to-feed ... / /link Pro: * Groups the two links together * Gives us more options for what to call the inside one without creating confusion: source-feed, for example. It would be nice to choose a name that's not likely to be the perfect name for some other use, or to define this @rel value broadly enough to be applicable to other purposes. Con: * Puts an atom:link in a location not expected by apps that don't understand this extension.
Re: Comments Draft
* Justin Fletcher [EMAIL PROTECTED] [2005-07-30 23:25]: I'm quite happy with 'replies-source' because it does not indComparing to mail seems to be a reasonable thing to do - mail has a considerable amount of prior implementation and understanding from which concepts can be drawn. However, there is no equivilent in mail terms for the purpose of the 'replies-source'. I’m -1 on using “replies-source”; I should have said so more explicitly before. To me it is non-sensical, as it parses as “the source of replies,” which is the opposite relationship of what it’s supposed to express. It’s not where the replies come from, it’s where the entries being replied to come from. I suppose the criticism on “thread-start” and “references” is valid… but I still think that “references” is linguistically the closest to what we are trying to express. Maybe “references-source?” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: atom buttons
I'm using the one from the Feed Validator. http://www.snellspace.com/public/valid-atom.png A. Pagaltzis wrote: * Bill de hÓra [EMAIL PROTECTED] [2005-07-30 18:40]: what are y'all using for Atom buttons? I’m not using one, but I thought there was one with the atom from the Atom logo? I can’t find any such thing now, though; well, except the one at the feedvalidator, but that’s too large for my taste. Isn’t there a vector version of the logo available somewhere? This is something that always irks me; most people post their logos only as bitmaps, so it’s impossible to use them with page background colours other than the ones they provided for, or to scale the logo sanely, or make a smaller text-less logo from a button, or such. Regards,
Re: Comments Draft
I agree. I'd much rather avoid introducing a new namespace for this tho. Nested link elements if just fine I think link rel=in-reply-to href=... link rel=source href=... / /link Using source in this context I think avoids the potential confusion had the link appeared without nesting. The fact that it solves the problem of associating a single in-reply-to to a single source location is an added bonus. Definitely works for me. A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-07-30 23:05]: Pro: * Groups the two links together * Gives us more options for what to call the inside one without creating confusion: source-feed, for example. It would be nice to choose a name that's not likely to be the perfect name for some other use, or to define this @rel value broadly enough to be applicable to other purposes. Con: * Puts an atom:link in a location not expected by apps that don't understand this extension. I like it. I’d prefer to eliminate the one contra you listed by using an extension element for this purpose (as always, nested into the link.) Of course, that means need a namespace… It’s a good solution to the bikeshed of naming the relationship, and it keeps the information about the entry being replied to and its source coupled together. With a plain old @rel value, you can’t tell which ones belong together in an entry with several links of both kinds. So far I can’t really make up my mind on any one solution, but this one seems the most correct, all else considered. Regards,
Re: Comments Draft
One challenge is that for anything besides references to Atom entries, there is no guarantee that in-reply-to links will be non-traversable. For instance, if someone were to go and define a behavior for using in-reply-to with RSS, the href of the link may point to the same URL that the RSS item's link element points to (given that there is no way to uniquely identify an RSS item). link rel=in-reply-to type=text/html href=http://www.example.com/entries/1; / This is legal in the spec but is left undefined. - James Antone Roundy wrote: On Saturday, July 30, 2005, at 03:59 PM, A. Pagaltzis wrote: I’d prefer to eliminate the one contra you listed by using an extension element for this purpose (as always, nested into the link.) Of course, that means need a namespace… Given that the link to the feed is traversable, and the link to the ID of the entry may not be, I'd suggest using an extension element for the possibly-non-traversable link, if for eitherwhich would leave us needing to pick a good @rel value for the traversable one. That would also keep my con point around: foo:non-traversable-reference id-of-other-entry=... link ... / /foo:non-traversable-reference ...unless it were done this way: link ... foo:non-traversable-reference id-of-other-entry=... / /link ...but doesn't quite work, because the logical relationships between the elements are entry to foo:non-traversable and foo:non-traversable to link, not entry to link and link to foo:non-traversable. I'm satisfied to live with the negative point of having a link in an unexpected place. And since I don't like non-traversable atom:links, I myself prefer foo:non-traversablelink//foo:non-traversable, though I don't expect it to be adopted.
Re: Comments Draft
On Saturday, July 30, 2005, at 04:37 PM, James M Snell wrote: One challenge is that for anything besides references to Atom entries, there is no guarantee that in-reply-to links will be non-traversable. For instance, if someone were to go and define a behavior for using in-reply-to with RSS, the href of the link may point to the same URL that the RSS item's link element points to (given that there is no way to uniquely identify an RSS item). link rel=in-reply-to type=text/html href=http://www.example.com/entries/1; / This is legal in the spec but is left undefined. The natural choice of values when replying to an RSS 2.x item would be the guid, since it's the closest counterpart to atom:id. But if the guid is not a permalink (ie. not dereferencable), then it won't have a MIME type, just as non-dereferencable atom:id's don't have a MIME type. Both of these facts suggest that the following sentence should probably be removed from section 3: If the type attribute is omitted, it's value is assumed to be application/atom+xml. Instead, I'd suggest stating that if the type attribute is omitted, the in-reply-to link cannot be assumed to be dereferencable, and that non-dereferencable links MUST NOT have a type attribute. Editorial notes about this sentence: A type attribute value of application/atom+xml indicates that the resource being responded to is an atom:entry and that the href attribute MUST specify the value of the parent entries atom:id element. 1) parent probably isn't the best word here since in-reply-to isn't being defined in terms of parents and children. 2) entries - entry's I could add more, but instead, here's my suggestion for replacing that sentence: If the resource being replied to is an atom:entry, the value of the href attribute MUST be the atom:id of the atom:entry. If the value of the type attribute is application/atom+xml then the href attribute MUST be the (URL/URI/IRI) of an Atom Entry Document containing the atom:entry being replied to. Anything else could lead to inconsistencies. For example, when replying to an atom:entry that can be found in an Atom Entry Document, but whose atom:id does NOT point to that document, there would be multiple choices available for the reply link's href attribute.
Re: Comments Draft
Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote: link rel=in-reply-to ... link rel=in-reply-to-feed ... / /link I'm not at all keen on extending the link element in this way. Atom Publishing Servers that don't know about this extension that receive an entry containing nested links from a publishing client will most likely drop the content of the link and publish it to clients without the inner link. I don't believe that atom:link isn't usefully extensible other than by creating new @rel values; or if you want something more powerful, use extension elements. Atom's extensibility framework has been touted as one of Atom's major advantages[1] over RSS. Nested link elements sound a bit too much like [2], but without the namespaces constraint. [1] http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared#x [2] http://blogs.law.harvard.edu/tech/rss#extendingRss -- Dave
Re: Comments Draft
Sunday, July 31, 2005, 1:09:44 AM, I wrote: I don't believe that atom:link _isn't_ usefully extensible other than by er, that should be is -- Dave
Re: Comments Draft
On 31/7/05 7:47 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: I¹m -1 on using ³replies-source²; I should have said so more explicitly before. To me it is non-sensical, as it parses as ³the source of replies,² which is the opposite relationship of what it¹s supposed to express. It¹s not where the replies come from, it¹s where the entries being replied to come from. original-replies-target? e.
