Re: self and alternate links for entries
2007/1/30, Bill de hOra: I'm building a tool (for Plone) at the moment that will publish any content as an Atom Entry by appending '/entry.xml' onto the URL. I had a question about declaring self and alternate links. Here are two options: 1: @rel=self,@type=application/xml+atom links to the Entry @rel=alternate, @hreflang, @type, links to the Content 2: @rel=self @hreflang, @type, links to the Content @rel=alternate, @type=application/xml+atom links to the Entry I couldn't find enough information in the RFC about which way to go. Which would you choose, and why? #1, because: a. I understand "self" as "myself" b. rel="self" was initially added –even though that does not appear in the spec– so that feed readers do not have to know the IRI where the feed was downloaded, they can just read a byte-stream and the feed-level will tell them that IRI. For entry-level such links, I would expect the same: where could I download this "file" when nobody gave me its IRI? -- Thomas Broyer
Re: within HTML content
2007/1/1, Geoffrey Sneddon:
On 1 Jan 2007, at 16:59, Asbjørn Ulsberg wrote:
> the element has no place in an HTML fragment, so its meaning
> is (although most browsers wrongfully supports its presence
> anywhere in an HTML document) unspecified.
Web Applications 1.0 (keeping with the real world) defines that it
should be moved to HEAD within the DOM tree.
I suppose HTML within Atom is rather processed as "innerHTML", so
there is no "head pointer", and the element is just appended as
a child of the current node (along with a "parse error" !)
Why, may I ask, MUST (under the RFC 2119 definition) HTML content be
a fragment ("HTML markup within SHOULD be such that it could validly
appear directly within an HTML element, after unescaping." -
note the word SHOULD, not MUST, implying that you can have a full
HTML document within)?
Yes, you could, in the sense that the Atom document wouldn't be
"invalid", but you shouldn't expect it to be processed as a "full HTML
document".
The "SHOULD" implies that Atom processors are OK if they process HTML
"content" as "innerHTML" on a element.
--
Thomas Broyer
Re: Atom Entry docs
2006/12/14, Tim Bray: Bob Wyman wrote: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. In case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say "yeah what Bob said" your co-chairs would probably do a hasty consensus grab. Just in case: "yeah what Bob said" ;-) -- Thomas Broyer
Re: Atom Entry docs
2006/12/14, Bob Wyman: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. It was exactly the point behind my proposal for this 'type' parameter. -- Thomas Broyer
Re: PaceEntryMediatype
[CC'ing the WHATWG list] 2006/12/7, Jan Algermissen: Seriously: how many feed readers are out there that base the decision wheter something is subscribeable on the type attribute of a link rather then on the link type? Every one? Oh, they also look at the rel="alternate", but I'm pretty sure they won't "process" the link if the 'type' attribute is absent, and they don't "process" it if it's present with a value different from the Atom or RSS media type. As an analogy: HTML browsers look for stylesheets where it says and not Eh? Let's take two files, index.html and style.css. Now, let's describe the relationship between them. What is style.css wrt index.html? a stylesheet that browsers should use to present index.html. What is index.html wrt style.css? a page that uses style.css as a stylesheet. The relation really *is* "stylesheet" (when taken from the page to the stylesheet), whether it is written in CSS, XSLT->XSL-FO, DSSSL, etc. Now, let's take a "blog entry page" and the "blog feed" and try to describe the relationship between them. What is the blog entry page wrt the blog feed? a resource that is being or has been linked from the feed as one of its "items". If you see a feed as a set of entries not restricted to the limited set exposed by its representations, the entry is still part of the feed. What is the blog feed wrt the blog entry page? a feed (set of entries, bla bla bla) which is linking or has been linking to the entry page as one of its "items". The relation in this case is "feed" (when taken from the entry page to the feed; note that rel="feed" here is *not* the same as the one from the current HTML5 draft). What's clear is that it is not "alternate", as used today for feed autodiscovery. This rel="feed" is IMO useful because that's what people are generally looking at when they want to "subscribe to a site" and are not already looking at an "HTML feed": where's the feed which contains this item? Last example, in two parts: Let's start with Mozillazine's homepage and its Atom0.3 feed; they are clearly rel="alternate" representations of the same thing: a feed (set of entries, bla bla bla). The HTML version also contains sidebars with additional information, but they're not part of the "main content". Now, let's take, say the Mozilla.org homepage. It is linking to Mozillazine and its feed. I don't know how we could describe the relationship between Mozilla.org and Mozillazine and that's not the point here, so let's call it "X". If Mozilla.org is linking to Mozillazine using rel="X" and given that Mozillazine's homepage and Atom0.3 feed are alternates; Mozilla.org should also be linking to Mozillazine's Atom0.3 feed using rel="X" (which it does in an in the of the page, where actually it uses no rel="" at all). So why the hell is it using rel="alternate"? (in a in the section). As Mozillazine's Atom0.3 feed is an alternate representation of the Mozillazine's homepage, does it mean that Mozilla.org and Mozillazine also are rel="alternate"? I'd say no, however that's what rel="alternate" implies (it has been re-enforced in HTML5 that rel="alternate" is transitive). If rel="" on and had a default value (let's say rel="related"), then this value could be used in the required rel="" attribute of when linking to feeds which are neither rel="alternate" or rel="feed" (with the definition given above, *not* the one from HTML5): http://www.mozilazine.org/atom.xml"; type="application/atom+xml" title="Mozillazine News"> My last point: if the rel="feed" as described above seems useless, then I'm not opposed to having a rel="feed" "marker" as defined in the current HTML5 draft, with an addition: that this "feed" marker be "combinable" with any link rel: rel="feed alternate", rel="feed up", rel="feed index", etc. (and at the condition that it is explicitely defined as a "marker" and not as a relationship; rel="prefetch" and rel="nofollow" would also need this distinction). -- Thomas Broyer
Re: PaceEntryMediatype
2006/12/2, Antone Roundy: Now that this has sunk in, it makes a lot of sense--the @rel value says "you can subscribe to that", Why would I subscribe? is it an alternate representation of what I'm looking at? or the feed containing the article I'm looking at? or a totally distinct resource that might interest me if I'm interested in what I'm looking at (think about blogrolls and the "people who bought this also bought that and that" links)? By saying "you can subscribe to that", you're not describing a relation. Maybe you're describing a facet of the resource the link points to, but is this objective or subjective? If it's meant to be objective, then the media type is enough (am I *able* to subscribe to such a thing), or maybe there's a need for another kind of metadata (I proposed a new 'subscribable' attribute on the WHATWG list). The media type helps the user agent figure out whether it has the capability to do those things. For example, a feed reader that only handles RSS could ignore subscription links to resources of type "application/atom+xml" (ie. not present the subscription option to the user). And if an UA has the capability to subscribe to something, why couldn't it provide a mean to subscribe, whichever the relationship? What would be important is to reflect the relationship on the UI so the user have all the information available to choose whether he *wants* to subscribe. The "subscribe to hAtom feed" case where @type is "text/ html" might be a little difficult to make a decision on, because there's no indication of what microformat is being used by the "feed" (or even if there's a microformat in use at all--maybe it really is just an HTML page, and "subscribing" to it just means "watch for changes to the entire document"). ...or it's an HTML5 page making use of the new element... One problem that I hadn't really thought clearly about till right now is that understanding the nature of the think linked TO may require some understanding of the nature of the thing linked FROM. For example, an "alternate" link from a typical blog homepage to its feed really does point to the same thing in an alternative format. Both are live documents in which new data gets added to the top, and old data drops off the bottom. But if you don't know that the webpage is a live document, you wouldn't know whether the link pointed to a static or live document. "alternate" is perfectly accurate, but it's not helpful enough. "subscribe" would be much more explicit. Why should it be automated? When you go read a web site every morning because you know it's "live", it's not automated. What you could automate is how to go read that site (e.g. use it as your browser's "start page", or include it in a bunch of bookmarks you "open in tabs" every morning). There's not always a need to automate everything. Things like "whether it'd be interesting to subscribe to something" are better handled by humans than computers. -- Thomas Broyer
Re: PaceEntryMediatype
2006/11/30, Mark Baker:
The real problem here AIUI - at least in the context of HTML 5's
inferred rel="feed" bit - is not just entry documents, it's any Atom
document which wouldn't normally be considered a "feed" by a typical
user; something that most people would be interested in subscribing
to. An example I gave on the whatwg list was an MHTML-like (MIME
multipart) package, but there are many other possible examples of
course; not all RFC 4287 feed documents are "feeds" in this sense.
Yes.
If HTML 5 (and current practice) doesn't change, but we defer to them
for the specification of autodiscovery, then a new media type would be
one way forward. But it should be reusable for all non-"feed" (i.e.
from a user POV, as above) Atom documents, not just entry documents;
perhaps application/atom-no-feed+xml. It's an ugly hack, but it's
better than the alternative of many more specific Atom-related media
types, which atomentry+xml might set a precedent for.
-1
This means RSS would need two media types.
This also means an HTML document can be a "feed", or it needs its own
media type.
In an "entry" page in a blog-like scenario, we could find:
which tells you the page "believes" it is an "item" in the linked "feeds".
Then , in /feed.atom:
and in the "/":
And yes, HTML pages are "subscribable", either using a microformat
(see the W3C's home page, from which the RSS is actually produced
using an XSLT stylesheet), or using user-defined "scrapping" (some
aggregators allow you to subscribe to any web page; they try to infer
the "entries" from the semantical markup –h1, h2, h3, etc.– and you
can customize the mechanism in per-feed basis: this page uses h2, this
one uses h3 with class="article", etc.)
The relation from the "entry" page to the feed or "home page" is the
same (hey, they are alternates!): they are "feeds", whatever their
representation (Atom, RSS, HTML, etc.)
The difference with "container"? a "feed" is known to have a
representation which only exposes a subset of the contained items.
This is the same as:
Another way forward, because the rel="feed" inference is triggered not
just by the media type but by the "alternate" relationship keyword, is
to create a non-feed alternate relationship ("alternate-non-feed"?
ick).
I prefer the new relationship to a new media type because it's less
disruptive; it doesn't require futzing around with existing specs and
implementations.
I'd prefer basing autodiscovery on the media types and not at all on
the relationships. A "feed" relationship would only help finding the
"living resource" (similar to rel="current" in the Atom Relationship
Registry) if you're not already "on" it (in which case,
rel="alternate" would be used).
UAs would then obviously continue to support autodiscovery using
"alternate" all-over-the-place, this would just be a lucky
side-effect; and everyone would be happy.
--
Thomas Broyer
Re: PaceEntryMediatype
2006/11/29, James M Snell:
Create a new media type for Atom Entry Documents: application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
I'd largely prefer augmenting the existing media type with a 'type' parameter:
- application/atom+xml => either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed => feed
- application/atom+xml;type=entry => entry
{{{
Atom Entry Documents are identified with the
"application/atomentry+xml" media type (See section 15).
}}}
How about defining a "tree" similar to the */vnd.* one?
- application/atom+xml => feed or entry document
- application/atom.categories+xml => category document
- application/atom.service+xml => service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml => entry document
As for Tim's concerns, I'd also prefer having it done outside the APP.
Also, the APP draft would need to be updated to remove the "entry"
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)
--
Thomas Broyer
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, "If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well." It goes on to say, "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" The problem with this is that the "application/atom+xml" media type is also used for Atom Entry Documents: The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the "updated media-type" fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
2006/11/28, Robert Sayre: Nonsense. You know very well that projects I work on will get bug reports on "standards" compliance if you change something. So, yes, I do have to waste my time here. Since I maintain autodiscovery code people actually use, you'd think my opinion would count for something. If autodiscovery could be defined as in [1], I'd happy to see Firefox (and IE7) have bug reports on "standards" compliance: I do not use current autodiscovery implementations because I'm not confident in their (undocumented) behavior (among other things, like integration with external aggregators). I'd like autodiscovery documented somewhere, but not as a documentation of current practices (which I think are Bad Things), rather as "clean" way to do it. However, if any spec (informational or not) tends to only document what's already done, be sure I'll try to "kiil it before it's done". -- Thomas Broyer
Re: PaceMakeAutodiscoveryInformational
2006/11/28, Robert Sayre: The WHAT-WG text is fine. -1 For various reasons, including: http://www.imc.org/atom-syntax/mail-archive/msg19100.html http://www.imc.org/atom-syntax/mail-archive/msg19107.html -- Thomas Broyer
Re: PaceResurrectAutodiscovery
2006/11/24, Henri Sivonen: On Nov 24, 2006, at 10:28, Thomas Broyer wrote: > My main problem with autodiscovery is this use case: the following > links on an "entry page" in a blog-like scenario, where comments on > the entry are shown at the bottom of the page: > title="A standalone Atom Entry alternate representation, might > even be updatable using HTTP PUT" /> ... > 1. the first one should not be seen as a "feed" link; That ship sailed long ago. For backwards compatibility, UAs will treat links like the one quoted above as feed autodiscovery links-- not as standalone APP editing links. It is too late to apply elegance retroactively. …except if you update application/atom+xml to add a type=entry parameter... in which case the existing code will probably won't "find" the link... In the absence of 'type' parameter, you have no mean to know whether the Atom DOcument is a feed or entry, so you treat it as a "possible feed", just in case. And you're backwards compatible. -- Thomas Broyer
Re: PaceResurrectAutodiscovery
2006/11/23, Henry Story:
On 23 Nov 2006, at 14:28, Thomas Broyer wrote:
>
>> "The feed keyword indicates that the referenced document is a
>> syndication feed.
>
> "Being a syndication feed" is expressed by the media type, there's no
> need for a 'rel' value.
>
> The only reason for such a 'rel' is to replace the "contents" value in
> the example above:
>
>
> in "blog-like" use-cases where an HTML page serves the same purpose as
> a syndication feed, just in an 'alternate' format.
Exactly: you have just made one good point why one should not use
mime types to identify the relation. After all there may be many
different feed representations: html, rss 1.0, rss 2.0, atom,
rdf, ... etc...
My problem is that:
1. there is no need for a "feed alternate" as spec'd by the WhatWG:
- when you (as an autodiscovery tool) look at a resource, it might
point to a 'feed' within which it is an 'entry' (or 'item'), this
'feed' might be many different formats, if it happens that you know
how to subscribe to one of the proposed formats, you can provide a
"subscribe to feed" ("within which the current 'page' is an 'item'"
implied) button;
- when you look at resource which is a 'feed' (and this kind of
thing cannot be "autodiscovered"), then you'll have links to other
formats as 'alternate's, if it happens that you know how to subscribe
to on the proposed formats, you can provide a "subscribe to _this_
feed" (or "subscribe to this page") button
The condition to show a "subscribe" button is whether you know how to
deal with the format, the text you'll use on the button depends on the
relation of this "feed resource" wrt the "current page".
2. stating that if rel="alternate" and @type is RSS or Atom (feed or
entry), then treat the same as rel="feed alternate" is a Bad Thing:
the 'alternate' might be a standalone Atom entry, or might be an
"archive feed": in the former case, a type=entry would disambiguate
it; in the latter case, you'll still provide a "subscribe button"
(because you have no mean to detect it is an "archive feed" without
downloading it) but when the user will click it and you'll dereference
the link, you'll pop up a "the feed is marked as being an archive,
which means it won't be updated, are you sure you want to subscribe?"
message box. If the feed has a with a @type you
know how to deal with, you can change the message box to add "however
the feed provides the location of a 'living feed', do you want to
subscribe to this one instead?".
So, what I'm saying is: I'm not willing to use media types to identify
relations (the fact that you can technically subscribe to a thing
depends on the format of that thing, whether you can parse it or not),
I'm willing NOT TO use relations to identify "groups of media types"
(the ones looking like feed: a container with metadata and contained
items with their own metadata).
Last, but not least, "alternate stylesheet" has a special meaning, and
using "alternate feed" in a different way is a bit confusing...
My main problem with autodiscovery is this use case: the following
links on an "entry page" in a blog-like scenario, where comments on
the entry are shown at the bottom of the page:
1. the first one should not be seen as a "feed" link; I'm proposing
adding a type=entry parameter to the application/atom+xml media type
to help disambiguation; I'm also disagreeing here with the rule of the
WhatWG (rel="alternate" + "feed" media type => rel="feed alternate")
2. which values to give to XXX and YYY?
If XXX is 'alternate', then you need a type=feed parameter not to
confuse the two first links.
XXX and YYY should not be the same, the relations are not the same:
XXX is "contained" while YYY is a "container".
I'm proposing XXX=alternate and YYY=feed; along with adding a
type={feed,entry} to the application/atom+xml media type.
There are many other good reasons to not use the "alternate" relation
everywhere. The spec [1] for feed makes the case for a useful
distinction between a feed that can be used to track updates of the
content one is looking at,
You don't need a special format for that, you could just regularly
poll the resource with If-Modified-Since and If-None-Match.
A special format (which would just be an 'alternate', and nothing
more) helps present it in a unified way along different web sites.
and something that is just an alternate representation of the content
one is looking at expressed in application/atom+xml format.
That would be 'feed alternate'? If so, then your other case above does
not fall in the 'feed' case: from the WhatWG, "otherwise, the feed is
just a syndication feed, not necessarily
associated with a particular Web page": how can you describe a
relationship between to things (that's what is doing a link) and at
the same time say that the other end of the link is "not associated
with a particular Web page"?
This would be the case for the front of my blog page.
rel=alternate is enough in this case.
--
Thomas Broyer
Re: PaceResurrectAutodiscovery
2006/11/23, Henri Sivonen: The latest WA 1.0 draft covers this as follows: "If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well." http://whatwg.org/specs/web-apps/current-work/#alternate0 This conforts me in thinking that the application/atom+xml media type should be updated to add a "type" parameter with values "feed" and "entry". There would be no ambiguity between these two links: I expect aggregators to allow me to subscribe to feeds (subscribe in the sense or "watch for new –or updated– entries) or individual entries (subscribe in the sense of "watch for updates"). With rel="alternate" and an RSS or Atom media type, those aggregators could show a "subscribe to this page" button. With an RSS or Atom media type and another 'rel', they could a "subscribe to [EMAIL PROTECTED]" button. For example, with these two links: a browser could show "Go to Table of Contents" and "Subscribe to Table of Contents" buttons. "The feed keyword indicates that the referenced document is a syndication feed. "Being a syndication feed" is expressed by the media type, there's no need for a 'rel' value. The only reason for such a 'rel' is to replace the "contents" value in the example above: in "blog-like" use-cases where an HTML page serves the same purpose as a syndication feed, just in an 'alternate' format. -- Thomas Broyer
Re: The "src" attribute of atom:content
2006/11/22, Tse Shing Chi (Franklin/Whale): There is an unexpected reply located in http://www.imc.org/atom-protocol/mail-archive/msg07722.html. Oops, sorry! (double-checked, this time, I answer to atom-syntax ;-) ) Quote: ... I don't know how to display such a content within a widget, however I know there is some program in the "registry" (Windows Registry, Freedesktop's shared MIME database, OS X configuration, etc.) which is able to open it; so I whot the summary (if any) and provide "Open with..." and "Save as..." buttons. I couldn't do that with an xhtml:object embeded in an (or eventually type="html"). It is almost what I want aggregators to do actually. However, web-based aggregators may have difficulties in handling it. They could "display" the summary and provide a "Download the entry content" link. If they know how to "display" the content, then they can generate HTML code (an xhtml:object) with fallback to the summary: If you see this message, it generally means your browser does not know how to display content of type "image/svg+xml". However, the entry publisher has provided this summary for you to read: ...entry's summary... Download the entry content... Currently, the way to provide alternate format or text... seems to be the followings. I personnaly have no problem with a summary acting as an alternate text (to display if the content can't be): hey, there's a valid reason why summary must be provided if the content is out-of-line or base64-encoded ;-) Alternate "formats" should be linked to using Anyway, no one can ensure that aggregators will display the summary when they are [NOT] able to show the content. Right, but I hope and expect those aggregators to either be updated or tend to disappear (because people will switch to "better" aggregators). -- Thomas Broyer
Re: categories and tagging
2006/11/2, Henry Story: On 2 Nov 2006, at 12:19, Thomas Broyer wrote: > >> [[ >> The "term" attribute is a string that identifies the category to >> which the entry or feed belongs. Category elements MUST have a "term" >> attribute. >> ]] >> >> nowhere is there mentioned a IRI there, > > IRIs are not forbidden either, and Andrew's description makes me think > the "concept URI" *is* the "term". The question is: how does this help any of us? It may look like it is a "term", but what is a client meant to do with all this information? Nothing. A client is not meant to do anything with atom:category elements other than for categorizing the entry or feed. So if Tim Bray uses Then what am I meant to do with this info? You can tell the reader that the entry is in the "Places" category, you can provide a "show other entries within this category" feature, you can group entries by their category (in a treeview: root nodes are the list of schemes, their child nodes are the list of terms, presented using the provided @label; if there are different @label used, you can default to the latest and provide a tooltip or other contextual info such as "a.k.a. Locations, Where"), etc. Since scheme is a URL I can presumably go there to find something. But what? Some people also want to dereference XML Namespaces' URIs. Term is not defined to be a URI, and in the above example it is not, and so why should I do anything with the term below? http://my.scheme.net/my-vocabulary/"; term="http://my.concept.net/my-vocabulary/13745"; label="cats" /> There's no reason you would do anything with it either. What I am proposing is that we put forward some best practice to formalize a useful and RESTful way to publish this information, so that clients can use it. With APP we could do something like this: we could define for example that when entries are published and they contain categories that have a scheme that is accepted by the collection, then the entry will be found in the feed that is to be found either by appending scheme+term or in the catid location I mentioned previously. -1 But you can still do it yourself in your own implementation, eventually with the use of an f:feature to communicate the feature to clients. So if Tim Bray posts an entry containing ... and his collection manages the <http://www.tbray.org/ongoing/What/> scheme, as defined perhaps in the service document, (and perhaps we can place the list of available categories at that scheme location!) then his client will know that the entry will also be found in the <http://www.tbray.org/ongoing/What/Places> collection. I don't see how this is useful, but you might have good reasons. Now this would be useful for an APP publishing client, and it would be useful for an APP reader, because it could find some useful information at these various locations, I understand the need to provide a "category URI" in some scenarios but that should be an extension to the atom:category element or a "mapping mechanism" communicated by a feed-level or entry-level extension, but please no "global assumption". and it would save us having to define an unending number of link relations that parallel the categories we have, when it is in fact clear that everybody intends to use scheme+term as a uri. Do you mean scheme+term, scheme+"/"+term or scheme+"#"+term? or maybe scheme+"/"+term+".atom"? or scheme+"/tags/"+term? -- Thomas Broyer
Re: categories and tagging
2006/11/2, Henry Story: On 2 Nov 2006, at 08:59, Thomas Broyer wrote: > [redirecting to atom-syntax] This is also a protocol issue, because we are asking what to do with the information in the atom feed. [1] Not sure how atom-protocol is concerned but let's keep it in atom-protocol too... > 2006/11/1, Houghton,Andrew: >> >> concept scheme URI: http://my.scheme.net/my-vocabulary/ >> concept URI:http://my.concept.net/my-vocabulary/13745 >scheme="http://my.scheme.net/my-vocabulary/"; > term="http://my.concept.net/my-vocabulary/13745"; > label="cats" > /> Thomas, I don't think that this is a natural reading of "term" in the atom syntax list. Andrew Houghton was talking about SKOS (which I don't know anything about) and said: [[ However, in SKOS you have a URI to the concept "cats", period. You could map the domain to be the SKOS concept scheme's URI and use the concepts label as the category content in Atom. But concatenating the SKOS concept scheme URI and the concept label doesn't necessarily produce the URI to the concept. For example, in SKOS you might have the following: concept scheme URI: http://my.categories.net/ concept URI for cats: http://my.categories.net/13745 concept label for cats: cats ]] My answer is a bare mapping of this description into an atom:category element. [[ The "term" attribute is a string that identifies the category to which the entry or feed belongs. Category elements MUST have a "term" attribute. ]] nowhere is there mentioned a IRI there, IRIs are not forbidden either, and Andrew's description makes me think the "concept URI" *is* the "term". -- Thomas Broyer
Re: categories and tagging
[redirecting to atom-syntax] 2006/11/1, Houghton,Andrew: concept scheme URI: http://my.scheme.net/my-vocabulary/ concept URI:http://my.concept.net/my-vocabulary/13745 http://my.scheme.net/my-vocabulary/"; term="http://my.concept.net/my-vocabulary/13745"; label="cats" /> -- Thomas Broyer
Re: Adding POST capability to atom:link
2006/10/26, Gopalan Sri: Jan, you are correct in your assessment that I wish to parameterize my request to go to the next page because my parameters are too complex to represent in a query string. Currently, we are representing our parameter in XML. The reasoning behind this is that we are trying to support an enterprise search operation using a SOAP and REST interfaces. Since we have to encode the request in XML for the SOAP interface, we were hoping to reuse that XML object within our REST based interfaces as well. We are using Atom to capture the results of enterprise search. The problem I encounter arises when we start thinking about the paging of results. For RESTful access to our services, we are trying to use open source/commercial Atom readers that support Open Search. The recommendations laid out by the OpenSearch 1.1 specification (http://www.opensearch.org/Specifications/OpenSearch/1.1#Example_of_OpenSearch_response_elements_in_Atom_1.0) suggest implementing paging with elements using specific values for @rel (e.g. self, first, previous, next, last). Right now I am trying to figure out how I can still follow their guidance while managing the fact that my parameter cannot easily be encoded as a regular query string. Any thoughts would be appreciated. Thanks for your time. I think your "search service" should create "temporary resources" and provide URIs for them to use in rel="next" links. A simple implementation is to store an object corresponding to the query parameters within a "Cache" or "Application" server-side object along with a "UniqueID", and then use that id in the URI to identify the query. The object would be removed from the cache/application after some delay of "inactivity". That's pretty easy in ASP.NET developments as the Cache object is provided out-of-the-box; there should be equivalents in the Java world too. -- Thomas Broyer
Re: Adding POST capability to atom:link
2006/10/26, Gopalan Sri: http://example.com/"; type="application/atom+xml" action="POST"> I hope such a thing won't ever exist !!! -- Thomas Broyer
Re: Question on undefinedAttribute/Content
2006/10/18, A. Pagaltzis: * Jan Algermissen <[EMAIL PROTECTED]> [2006-10-18 10:45]: > RFC4287 distinguishes between 'undefined' and 'extension' > constructs. I am understanding the distinction to imply that > conformant software should provide for handling extension > elements, but can and should ignore any occurrences of > undefinedAttribute or undefinedContent. > > Is that understanding correct? Yes. To be precise: Extension constructs are any markup which the software knows to interpret. Undefined markup is anything it doesn't know to interpret. In particular, this includes any future additions to Atom itself. Nope! Extension is what's covered by section 6.4, child elements of atom:entry, atom:feed, atom:source and Person constructs. Undefined markup is every other markup not defined by the spec: attributes on any atom:* element, and child elements and text inside other elements (atom:category, atom:link, etc.) Whether the application knows what to do with markup, it's still extension markup (e.g. thr:in-reply-to) or undefined markup (e.g. thr:replies-count). -- Thomas Broyer
Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07
2006/10/9, Andreas Sewe: But while the draft states that "[t]hese [feed] types are complementary" (section 1), but is unfortunately silent on how precisely the three different types can be used together. Here are a few questions I still have: - Is it possible that an Archived Feed Document is marked as complete? By definition, an Archived Feed is a set of Feed Documents, and an Archive Document is a Feed Document within that set. It cannot be "complete", unless it is the only one in the set, and therefore represents the whole Archived Feed as a single Feed Document. It's "current" link should then point to itself (i.e. the same as the "self" link). - Is it possible that a Paged Feed's pages (i.e., its feed documents) are marked as complete? No. By definition, a Complete Feed is a single Feed Document. See: 2. Complete Feeds A complete feed is a feed document that contains all of the entries of a logical feed; any entry not actually in the feed document SHOULD NOT be considered to be part of that feed. - Is it possible to serve a single, possibly large Archive Document as multiple pages? Not sure what you're talking about… Do you mean a Logical Feed would be split into "stable subsets", each such subset split into "unstable" Feed Documents? In this case, as each document is not "stable", it's a Paged Feed, not an Archived Feed, even if the subset of entries from within 2 Feed Documents form a "stable subset". If every Feed Document is "stable", then you have an Archived Feed an dyou can link Feed Documents to each others using next-archive and prev-archive. -- Thomas Broyer
Re: versioning extension?
2006/9/12, Jan Algermissen: is anybody working on (or planning to work on) a versioning extension for Atom? I am about to use Atom in two (considerably different) projects that require versioning and would be happy to join forces and contribute real (enterprise-)world use cases. (Note: not 'enterprisey' use cases :-) Have you looked at this? http://tools.ietf.org/wg/atompub/draft-snell-atompub-revision-00.txt -- Thomas Broyer
Re: Language Negotiation
2006/7/27, Eric Scheid: >> what would happen if you used conneg on the @rel='self' link (to the >> 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? Hmm, sorry, I think I didn't correctly understood you first question... ...at least I don't understand the second... -- Thomas Broyer
Re: Language Negotiation
2006/7/27, Eric Scheid: >> 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 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 -- Thomas Broyer
Re: Language Negotiation
2006/7/27, Sylvain Hellegouarch: > 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. True. If you buy a book in English and then the translation of that book in a different language you will end up with two books having each their own ISBN. Well, actually, once a book is published, if you later update it, you'll have to use a new ISBN, so that's probably not a good analogy… -- Thomas Broyer
Re: Language Negotiation
2006/7/27, James M Snell: And within feed documents in the form of language-qualified alternate links (e.g., , , etc) You rather meant , weren't you? ;-) From RFC4287: 1. The value "alternate" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element. […] 3. The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element. Here, you're linking to alternate versions of the resource (in alternate languages), not to an "equivalent" resource (it's not equivalent, because it's in another language). …using xml:base rather than would have been so much cleaner… …or maybe at least rather a or , because the rationale of rel="self" were "if an aggregator is given a copy of a feed without information about its original IRI, how can it find which URI to subscribe to?"… -- Thomas Broyer
Re: [RFC 4287] unicity of atom:category element
2006/6/26, Nicolas Krebs: Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287 ( http://tools.ietf.org/html/rfc4287#section-4.2.2 ) > 4.2.2.1. The "term" Attribute > The "term" attribute is a string that identifies the category Is the term attribute an unique identifiers ? My interpretation of atom:category is that scheme+term defines a unique identifier, much the same as a QName in XML. I might be wrong however, as RFC4287 is completely silent on this... How can i manage the homonym ? Use different categorization schemes ;-) Could an atom 1.0 feed contain some item whith " and other item with " Yes. Note that you could also have those two atom:category elements in the same atom:entry, as RFC4287 puts no constraint at all on categories (unlike atom:link elements). where the first Java is not the same as the second ? With the same scheme and term, aggregators (or other Atom processors) are very likely to consider them the exact same category. I think the producer of such a feed would be wrong using the same scheme and term for (conceptually) different categories... -- Thomas Broyer
Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.]
2006/6/9, Julian Reschke <[EMAIL PROTECTED]>: I think this is a misunderstanding of how HTTP/1.1 is supposed to work. If a server returns the same ETag for different entities returned for the same URL, this will cause breakage of caches. You may want to re-read Section 13.6 of RFC2616 (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.6>). But using A-IM, you'll have Cache-Control and Vary headers in responses, which should take care of that, no? (I'm at work have no time to read the pointed section carefully, so please forgive me if I'm wrong) -- Thomas Broyer
Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.]
2006/6/8, Mark Nottingham <[EMAIL PROTECTED]>:
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
>
> My main concern is that RFC3229 w/ feeds is being deployed more and
> more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also concerned that RFC3229 is an extension of HTTP, but some
implementers are acting as if it chages the semantics of already-
defined parts of HTTP. For example, a delta must be a subset of the
current representation that is returned to a GET; if you GET the
feed, it has to return all of the entries that you could retrieve by
using delta.
I have a feeling that many people are treating it as a dynamic query
mechanism that's capable of retrieving any entry that's ever been in
the feed, while still only returning the last n entries to a plain
GET. If so, they're breaking HTTP, breaking delta, and should use
something else.
Is this the case, or am I (happily) mistaken?
RFC3229 adds a new notion, the one of "instance" and defines that the
ETag is computed based on the instance, not the entity (difference
between instance and entity being the instance-manipulation –delta,
diff, or identity, which is the default in bare HTTP– having been
applied).
Now, let's define the "feed resource" as the complete set of entries,
and its default representation as one which shows only the most recent
ones (using a yet-to-be-defined conneg algorithm –e.g. using an
Accept-Features feature–, it could be possible to retrieve the whole
set of entries).
If I'm wront in the above statement (conneg could lead to a "latest
entries only" or "full", without abusing HTTP), then don't even read
further, this would mean that RFC3229 w/ feed changes the semantics of
existing parts of HTTP.
Let's take the steps in section 4 of RFC3229:
Conceptually, the various transformations are applied in the
following sequence:
1. Upon receiving a GET request, the server uses the URI in the
request to identify the requested resource.
2. Optionally, it uses information from the request (and perhaps
additional information) to select a variant of that resource.
The server might here use the presence of the A-IM request header to
select the "full" representation of the feed rather than the "latest
entries only" representations.
3. At this point, the server may apply a non-identity content-
coding to the instance, or one might have been inherent in its
generation. This also results in a Content-Encoding header.
4. The result of the first three steps, at the time when the
request is processed, is an instance. The instance includes a
body (possibly empty) and possibly some instance headers. The
entity tag, if any, is assigned at this point. That is, an
entity tag is associated with an instance, NOT an entity.
If I read RFC2616 correctly, nothing prevents the "latest entries
only" and "full" representations (or any representation of the same
resource) to share the same entity-tag, i.e. nothing prevents a server
to assign an entity-tag to a resource rather than its representations.
Maybe servers should use a weak etag in this case? But RFC2616 says in
section 13.3.3 that "Clients MAY issue simple (non-subrange) GET
requests with either weak validators or strong validators. Clients
MUST NOT use weak validators in other forms of request."
5. The server may then apply an instance-manipulation. For
example, if the request included a Range header, the server may
optionally produce a range response, consisting of the original
set of headers, a Content-Range header, and the appropriate
range(s) from the (possibly encoded) body. Delta encodings are
instance-manipulations, and are computed at this stage.
Given the ETag of the previous "version" of the feed, the server can
compute the delta and make it a feed of added and updated entries.
6. The result of the fifth step becomes the entity, consisting of
entity headers and an entity body.
7. The server may then apply a non-identity transfer-coding; on-
the-fly compression could be done in this step. If so, a
Transfer-Encoding header is added to the message.
8. The results of the seventh step is the message, consisting of a
message body (the transfer-coded version of the entity body),
the entity headers, and additional response and general
headers.
--
Thomas Broyer
Re: Paging, Feed History, etc.
2006/6/8, James Holderness <[EMAIL PROTECTED]>: Thomas Broyer wrote: > That means you need to keep entry revisions as well, so that if an > entry is updated while a client is navigating the paged result set, it > is sent the "old" revision (corresponding to the "date" parameter). Why? If an entry has been revised either don't send it (they'll get it then next time they refresh), or send it anyway (they'll just get it again the next time they refresh). Is that such a big deal? Or am I missing something? Sorry, I thought you wanted search engines to produce "snapshots"... (side note: but in this case, is there a need to pass a "date" parameter to following pages? and if pages are kind of "live", isn't there a risk of data loss? –I mean, this is the Web, so you'll end up doing the request for each page, just returning different chunks of the result set; if an entry changes between the request to the first page and the retrieval a following page, your request might put it somewhere else in the result set, changing ordering of entries based on updated time stamps, "discovery date", ranks or else, so your chunks would be different than if the entry hadn't changed, and an entry that have not been retrieved might end up in an already retrieved "chunk by page number", hence the client missing an entry– I think this is Mark's concern: this might be an acceptable behaviour in some cases but not all) > You're trying to change HTTP/1.1 behaviour wrt the If-None-Match > request-header field and the 304 (Not Modified) status code, so you > need to implement RFC3229 w/ feeds (which means dealing with some new > headers and a new status code). No change at all for *me*. As in my client. I already support FH. I already support Etags. I already support 3229. OK, I though you only supported Etags, as defined by HTTP/1.1 for efficient caching and bandwidth saving. > As I already said, I highly suggest not using paging for 226 (IM Used) > responses and rather fall back to "standard GET" in case there are too > many changes (i.e. behaving the same way as servers that don't support > RFC3229 w/ feeds). I don't get why this is a problem, but if you don't like it don't use it. Yep, sorry, this is not a problem. All I'm saying is, if you're a search engine and you what to create subscribable paged results, this is a method that you can use right now, and it will work with at least one existing FH capable client (I suspect others too). So we agree ;-) Could you read my recent mails in this thread and confirm that it's the case? The other proposal on the table is to change all your link names. Arguably a much better proposal than what I'm offering - it certainly seems to have got a lot of +1s - but it will work with precisely no one. So there now are two -1, isn't it? ;-) -- Thomas Broyer
Re: Paging, Feed History, etc.
2006/6/8, James Holderness <[EMAIL PROTECTED]>: Mark Nottingham wrote: > Are you talking about using ETag HTTP response headers, If-Match request > headers, and 304 Not Modified response status codes? That's a gross > misapplication of those mechanisms if so, and this will break > intermediaries along the path. For the first page I'm talking about an Etag (or Last-Modified) HTTP response header and If-None-Match (or If-Modified-Since) request headers for the retrievals a month later. What you described is RFC3229 w/ feeds [1], but you failed to include the new request and response headers and the specific status code, which are necessary because you're changing the behaviour of If-None-Match and 304 (Not Modified) as defined in HTTP/1.1. For page two onwards the state information (date, query and page number) comes from the link urls returned by the first page. That means you need to keep entry revisions as well, so that if an entry is updated while a client is navigating the paged result set, it is sent the "old" revision (corresponding to the "date" parameter). > Even if it's cast as a query parameter in the URI (for example), it > requires query support on the server side, a concept of "discovered time" > (as you point out), and places constraints on the ordering of the feed. The ordering is not necessarily important. As long as the server can filter out entries that don't match a specific time criteria it can return those entries in any order. Yes, ordering is not important. If ranking is necessary, then use the Feed Rank extension (but that means that potentially a great number of entries will be sent back as "modified" in 226 (IM Used) responses just because their ranking has changed) > Are you proposing this instead of the mechanism currently described in > FH? Alongside it? What I'm proposing would work with the FH as currently specified as long as the client supported ETag or Last-Modified as well. For me that means no change at all. You're trying to change HTTP/1.1 behaviour wrt the If-None-Match request-header field and the 304 (Not Modified) status code, so you need to implement RFC3229 w/ feeds (which means dealing with some new headers and a new status code). As I already said, I highly suggest not using paging for 226 (IM Used) responses and rather fall back to "standard GET" in case there are too many changes (i.e. behaving the same way as servers that don't support RFC3229 w/ feeds). My main concern is that RFC3229 w/ feeds is being deployed more and more widely and is still not even an I-D (or I missed something). Maybe FH could be the place to spec it, as another optimization algorithm… [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html -- Thomas Broyer
Re: when should two entries have the same id?
2006/6/7, Robert Yates <[EMAIL PROTECTED]>: Thomas Broyer wrote: > and that this is needed because entries > might not always be atomically retrieved (otherwise, "permaLinks" > would been enough). I don't understand what you mean "atomically retrieved" and hence why permaLinks would not have been enough. By "atomically retrieved", I mean that you don't necessary have an Atom Entry Document for each entry in a feed (actually, many CMSes don't currently provide Atom Entry Documents, the only Atom documents they provide are one or two feeds). As Atom goes beyond content management à la blogs, there are also use cases where the is no "alternate" representation: the entry in the feed is the only representation of the resource, there's no way to identify it using an URI, other than explicitely associate one through the atom:id element. Finally, atom:id is different from a permaLink in the sens that it's only an identifier that might not be dereferenceable (or, to be more accurate, that might not return anything but an error when dereferenced): it's not a link, it's an identifier, which has the form of an IRI, just as XML Namespaces are identified by URIs. The advantage of such a design choice is that you can move entries (hence changing "permaLinks") without changing their identifier. This is particularly useful when, for example, switching from TypePad to Blogger, and then to WordPress.Com, and then to a self-hosted blogging system, and then changing the blogging system (and changing feed and entry URIs, even if it's not a Good Thing [1]). A Good Practice for these identifiers –at least when you're an individual– is to make them "tag" URIs [2] [1] http://www.w3.org/Provider/Style/URI [2] http://www.taguri.org/ -- Thomas Broyer
Re: when should two entries have the same id?
2006/6/7, Henry Story <[EMAIL PROTECTED]>: You can have two entries or feeds with the same id, as long as they have different updated time stamps. It's very much the same as you being Robert Yates all your life, but having different sizes throughout your life. At any point in time you have all the same properties... Er, you can have two entries or feeds with the same if *and* updated time stamps, as long as –for entries– they do not appear in the same Atom Feed Document (and even this constraint might be removed in a later revision of the spec, if I recall some past discussions on this list correctly). What one need to remember is that atom:id is an identifier for the resource throughout its life, and that this is needed because entries might not always be atomically retrieved (otherwise, "permaLinks" would been enough). The atom:id is an identifier for the resource, not for the representation, so you might very well have the same entry (with the same atom:id) with inlined content in one feed and out-of-line content in another (or any other variation). The behavior of consumers when they meet those different Atom representations of the same entry is left undefined in the spec, and I personnaly have no opinion at all (as I have been given such feeds, and a) I'm not subscribed to any aggregate feed and b) I don't aggregate feeds I'm subscribed to, each one lives in its own "folder" in Thunderbird)… -- Thomas Broyer
Re: Paging, Feed History, etc.
2006/6/7, Mark Nottingham <[EMAIL PROTECTED]>: The degree of precision that FH currently provides isn't desirable for search results. Feed History also requires that the server maintain state about a particular feed, which is unworkable for search results; e.g., to implement feed history for search results, a server would have to mint a whole new set of feed documents for every query, and keep them around. That's not workable for most search engines (Yahoo, Google, Amazon, whatever), so they need another option -- one that needs to be clearly distinct from FH. This brings me to my other motivation -- I found that most people who use "previous" and "next" don't understand the assumptions that FH makes about archive stability, and point them at URIs like "http:// example.org/feed.atom?page=3". That will break the FH algorithm badly, reducing the value of the mechanism as a whole, because people will stop trusting it. The link relation for implementing the incremental approach needs to have the stability semantics baked in and explicit. As I previously said, the current FH algorithm isn't workable for all the use cases (notably with paged non-incremental feeds, those feeds being snapshots or "live feeds") but that doesn't mean there's a need for other rel values. I think FH could: - (more explicitly) RECOMMEND using stable "chunks" so that caching can be used (maybe using an "overview" section similar to the APP's section 5) - provide algorithms as an "how-to optimize bandwith et al. and not retrieve the whole set of pages/chunks", not as a "you should/must do that to comply to this spec" - provide different algorithms for incremental and non-incremental feeds, non-incremental feeds retrieval having to go through all the pages/chunks and not stop as soon as there's no more change (but the whole algorithm remains almost the same) - RECOMMEND using RFC3229 w/ feeds (problem: this is not an I-D), particularly for non-incremental feeds (Atom does not define order for the entries in the feed, order has to be told by extensions, e.g. Feed Rank, so there's no problem retrieving only a subset of the whole feed, even if new/updated entries would be sparsed in the feed if retrieved without RFC3229 w/ feeds), and NOT RECOMMEND (or even a "MUST NOT") using paging for RFC3229 responses: either you return the whole set of changes, or you choose to ignore the "IM" request and return the feed as if the client didn't use RFC3229) - use 304 (Not Modified) instead of IRI-comparison, enlightening the fact that web servers like Apache provide such response out-of-the-bow when delivering files (this should incite people to using stable chunks/pages by saving them to files, instead of making use of CGI applications with database requests). The fact that many implementations currently return feeds (whether or not they're using paging/history) without processing preconditions (If-Modified-Since or If-Not-Match) shouldn't influence the FH design, many of these implementations are deployments of CMSes like WordPress, and those can be fixed. Maybe the Feed Validator can have an option to test this: it would retrieve the feed twice (at least), using If-Modified-Since and/or If-Not-Match for the second request, and showing a warning if the feed hasn't changed and the second GET didn't result in a 304 (Not Modified). Please note that I haven't went back read the FH draft since weeks, so some of my comments might not be accurate (I've a pretty good memory but data-losses might still happen ;-) ) -- Thomas Broyer
Re: Paging, Feed History, etc.
vour of the more
generic "previous" and "next".
I think I originally pushed the other way around [1], but for
different reasons. If it's clear that previous/next deals with "pages"
or "chunks" of the same feed, then I'm OK with them, and other use
cases will need new rel values.
[1] http://www.imc.org/atom-syntax/mail-archive/msg17372.html
Given the above, I'd like to see if anyone would still object to
having separate relation sets for incremental feeds ("prev-archive"
and friends) and paging feeds ("previous", "next" and friends).
Given the above, yes. Consider it a "-0" though, not a "-1", as I
might need some more thinking (or people trying to convince me).
--
Thomas Broyer
Re: [RFC 4287] uri of atom:category element
2006/5/23, Nicolas Krebs <[EMAIL PROTECTED]>: Could you explain if there is a standardized way to fin the uri of the category, There isn't. an give piece of information about mandatory feature of sheme and term ? There isn't either. Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? wrong (because not aknowledged by the spec), allowed (because not explicitly forbidden). If it is a forbiden method, will you add an atom:href or atom:uri attribute to the atom:category element ? I'm not aware of any plan to do so. However, you might want to make up an extension. In this case, try to avoid using foreign attributes on the atom:category element or you'll run into the same problems James in fighting wrt his Fead Thread Extension [1]. The problem is that, as atom:category isn't listed in section 6.4 as containing Metadata Elements, there's no explicit request for processors to surface any extension to atom:category in their model representation, so they might just be discarded. IMO, the Simplest Thing That Could Possibily Work is to define a new link relation, say "category", and use atom:link elements to link to "category-related" resources. The drawback is that those atom:link elements won't be associated in any way to the atom:category elements, so aggregators/readers won't be able, for example, to list categories with links on the one where an "href" is provided, all they could do then is to list categories extracted from the atom:category elements and list "category links" extracted from the atom:link elements with rel="category", as two completely distinct sets. So finally, maybe a attribute or child-element -based extension might be better... On the rationale side, I suspect you want to link to an HTML page listing entries associated with the given category? First, I think this is a too specific case for a "generic" @href. I also don't see the need for it: those "category HTML pages" would generally be available from the HTML representation fo the entry (which I suspect would also exist), so they're only two clicks away. What _could_ be useful eventually would be a link to a *feed* containing entries associated with the given category, and in that case I think an atom:link with a new "category" relation would be enough. But even then I suspect "category feeds" to be not so common or not so commonly used (I'm personnaly not subscribed to any "category feed" and I don't even think sites I'm subscribed to provide "category feeds"; I'd like XML.com to provide an "articles only" feed instead of their "articles and blogs" feed, but that's not a matter of categories –"columns" are a category for articles, and blog posts have their own categories–). In conclusion: YAGNI. [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt -- Thomas Broyer
Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
2006/5/19, Paul Hoffman <[EMAIL PROTECTED]>: At 1:58 AM +0200 5/19/06, Robert Sayre wrote: >On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: >> >>This announcement is for a document that will obsolete RFC3548, which is >>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax >>(RFC4287). > >Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for >a revision. I'm confused. What breaks? +1 base32 and base32hex are for use in case insensitive contexts, but XML is case sensitive and Atom is XML. I can't find a real need for base16 and it doubles the size of the input, I'd say that Atom doesn't need it. Atom doesn't need base64url either, as + and / are not reserved characters in XML PCDATA (the only part of Atom where base64 is used). base64url might be useful on "data" URL though, but that's not the use of base64 encoding made by Atom. There's no reason for Atom not to support those encodings (other than because it introduces new encodings for processors to know about, and it would introduce a new attribute to tell processors which encoding has been used), but there's no reason for Atom to support any baseNN encoding other than the "plain old" base64. Having a single encoding is better for interop: implementors of processors/producers know exactly what to support; supporting multiple encodings would require an additional attribute telling which encoding has been used, which would lead to complains that this attribute's value set isn't extensible… So no, Atom shouldn't have to support other baseNN encodings than base64, and doing so wouldn't prove good for interop, so this revised RFC doesn't break Atom. -- Thomas Broyer
Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)
2006/5/5, Andreas Sewe <[EMAIL PROTECTED]>:
If the value of the "steps" attribute is "continuous" the set of rank
values defined by the r:values element is
{ x | minimum <= x <= maximum }.
And @origin is ignored?
Otherwise the set of rank values defined by the r:values element is
{ x | minimum <= x <= maximum,
x = (origin + i * steps) for some integer i }.
If "i" and "steps" are positive values, then "x" will always be
superior to "origin".
If "origin" is superior to "minimum", then "minimum" is not needed, as
"origin" *is* the minimum value.
If "origin" is less than "minimum", then "x" will always be superior
to "origin + i*steps" for which "i" is the minimum integer value
verifying "origin + i*steps >= minimum"; this is quite easy to
compute, so there's no real need for "minimum" either in this case:
the following r:values are all equivalent:
If "steps" is a negative value, its easy to compute the same set of
values using the minimum allowable value as the "origin" (or
"minimum") and a positive "steps". The following r:values are all
equivalent:
So: there is no need for "origin" and negative "steps" values.
There is however one case where that (converting a negative "steps"
value into a positive one) could not be possible: when "minimum"
equals "unbounded".
Couldn't it be spec'd that:
- if "minimum" is provided and not "unbounded", then "steps" counts
upwards from "minimum" to the greatest value inferior to "maximum"
- if "minimum" is not provided or "unbounded", then "steps" counts
downwards from "maximum" to negative infinity.
In other words, people transitioning from origin and/or negative-steps
have to do the following:
- if "steps" is negative and "minimum" is not "unbounded", replace
"minimum" with the smallest allowable value and use a positive "steps"
value
- if "steps" is negative and "minimum" is "unbounded", replace
"maximum" with the value of "origin" and use a positive "steps" value
(which will count downwards to negative infinity)
- if "steps" is positive, replace "minimum" with the value of "origin"
The following examples illustrate how different sets of rank values can
be defined by means of a single r:value element:
Could be expressed as:
or
or with the following r:values:
--
Thomas Broyer
Re: Feed thread update
2006/5/2, James M Snell <[EMAIL PROTECTED]>: Regarding the ref vs. href, issue, I really want to discourage client implementors from using the thr:replies as a link to the comment feed. Why? From what I read this week in other threads (about cloning the atom:link element, etc.), I think it could work. 1. define a "replies" link relation, so there is an atom:link pointing to the replies feed 2. define a thr:replies element with an @href and additional metadata (count, updated), clients are invited to use the thr:replies/@href and *not* to try to match the thr:replies element with an atom:[EMAIL PROTECTED]"replies"] ; if a "reader" processes thr:replies elements it should then ignore each and every atom:[EMAIL PROTECTED]"replies"]. Step 1 is either optional (do not define this "replies" link relation) or mandatory (require that there is an atom:[EMAIL PROTECTED]"replies"] matching each thr:replies element). Those three elements would have equivalent meaning, the last one adding extra metadata: Things would have been far easier if either a) atom:link were extensible or b) xml:base wasn't allowed on every element but only on "sections" (namely, atom:feed, atom:entry and atom:content) that can be included from other documents, so that you don't have to rewrite relative IRIs (I think that's the original rational behind xml:base), but that's not the case… To conclude, I think using attributes directly on atom:link is the thing to do, waiting for an amendment to RFC4287 to invite processors/parsers not to discard that extra metadata. The other choice is to totally remove those attributes, which is what you finally chose, I can't blame you. -- Thomas Broyer
Feed Thread Draft Updated
2006/4/13, James M Snell <[EMAIL PROTECTED]>: > a. Status quo. Leave things the way they are in the current draft >with a firm warning to implementors that not all atom impls >will be capable of supporting them. +1 > b. Drop thr:count and thr:when from the spec. +0.5 (and let someone add that metadata later if needed, in the same way as (a) or (d1) or maybe proposing something we haven't thought about) > c. Create a new replies extension element > type="..." > hreflang="..." > title="..." > count="..." > when="..." /> -0.5, it *is* a link > d. Create a supplemental extension element > >d1: > > > >Where the ref attribute in is a >unique identifier that can be matched to the >resource linked by the replies link. If only a >single replies link is specified, ref can be >omitted. There could be one thr:replies for >each replies link. -0.5, ugly but that's probably what would better match today's approach (in "a" above) >d2: > > > >only one thr:replies would be specified regardless >of the number of replies links. count would be >reflective of the total number of known replies >across all links. If I understand correctly, the use case for multiple "replies" link is, e.g., having a "comments" and a "trackbacks/pingbacks" feeds (could be distinguished by [EMAIL PROTECTED]). In this case, having a @count per link is IMO somewhat important. So -1. -- Thomas Broyer
Re: Changing feed thread (was: Re: Atom Thread Feed syntax)
2006/3/24, James M Snell <[EMAIL PROTECTED]>: > 1. Do I change to ? +0.5, I have no real problem with id but as it seems to bother some people… > and.. to address David's concerns about extending atom:link... > > 2. Do I change thr:count and thr:when to extension elements instead of > attributes on atom:link? +1 > None of the implementors I'm aware of are currently making use of > multiple replies link relations on an entry so changing #2 likely > wouldn't cause too many headaches. I wouldn't understand what really does mean the following: Without the thr:count, I'd say that those two links are intended for client-side content negotiation, but given that the two thr:count values differ… would it mean that there have been 5 new comments since the text/html representation has been last updated? But what if there were a thr:when indicating the opposite? And Rob Sayre also pointed on his blog a potential problem on how to use such multiple values: "How do I display that in a client? Do I add up the numbers? Pick the highest? Do I pick the latest or the earliest time?". [http://www.franklinmint.fm/blog/archives/000721.html] I know what your answer is [http://www.snellspace.com/wp/?p=297] but I also think that these are entry properties, not really link properties (so I disagree with you on "First, The thr:count and thr:when properties are specific to the replies link upon which they appear." [http://www.snellspace.com/wp/?p=296]). -- Thomas Broyer
Re: Atom Thread Feed syntax
2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>: > > It could lead to confusion, but as Atom doesn't define such an > > attribute in its own namespace (or on elements in its own namespace) > > and as no other extension that I know of do that either, I don't think > > it really matters… > > You are right Atom does not define such an attribute but I'd be happier > if extensions could follow Atom conventions as well. Atom sets the > atom:id value not as in an attribute of atom:id but as its content. Why > not following the convention in the first place? Because they don't deserve the same role. atom:id gives the identifier of the resource _described_ by the containing element, while thr:in-reply-to/@id gives the identifier of the resource _referenced_ by the containing element (or, actually, gives an identifier _as a reference_ to this resource). In that sense, thr:in-reply-to deserves the same role as @href. If you get back to previous versions of the threading extension, you'll see that it had been proposed that there would only be @href, whether or not the given IRI were to be dereferenced (e.g. by making an HTTP request) or just used as a globally unique identifier. This has been worked out because a) people (including me) wanted that these roles (retrieving vs. identifying) be clearly distinguished and b) there wouldn't then have a mean to give both the resource identifier and an IRI where to retrieve a copy of it. > > Having an attribute named "id" doesn't make it an "ID" (in the sense > > of a unique identifier throughout the document, such as the ID type in > > a DTD of xs:ID in XMLSchema), […] > > Again this is a matter of convention in my opinion. When reading an XML > document I don't want to be obliged to think about the actual meaning of > an id attribute. You are indeed right (and thank you for explaining it > to me) in terms of specification but conventions are often as important. > Specially for people like me who are not XML guru. Well, I wouldn't describe myself as an XML guru either ;-) -- Thomas Broyer
Re: Atom Thread Feed syntax
2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>: > Calling such an attribute 'id' is a mistake in my opinion as it confuses > with the actual ID of the element itself within the XML document it > belongs to It could lead to confusion, but as Atom doesn't define such an attribute in its own namespace (or on elements in its own namespace) and as no other extension that I know of do that either, I don't think it really matters… > and it makes impossible for another element within the document to > have the same value as an 'id'. In your blog, you actually wrote: > The other problem I have with naming this attribute id is that no other > element of the document can use the same attribute name and attribute > value since that within an XML document, these are unique (unless I am > mistaken of course). I'm sorry to have to tell you that you *are* mistaken… Having an attribute named "id" doesn't make it an "ID" (in the sense of a unique identifier throughout the document, such as the ID type in a DTD of xs:ID in XMLSchema), otherwise: - you wouldn't have to declare them explicitely in your DTDs and there wouldn't be a need for an ID (resp. xs:ID) type in DTD (resp. XMLSchema) - the validity constraint "One ID Per Element Type" [http://www.w3.org/TR/REC-xml/#one-id-per-el] could never be met as soon as you'd declare an ID attribute with a name different from "id" - there wouldn't have been a need for xml:id [http://www.w3.org/TR/xml-id/] > I would rather move the content of that attribute as a text element of the > 'in-reply-to' element (as does the atom:id element). Eventually, I'd rather rename it to resource-id… -- Thomas Broyer
Re: Atom syndication schema
2006/3/15, Stephane Bortzmeyer <[EMAIL PROTECTED]>: > Just to be pedantic, URIs (RFC 3986) are in pure US-ASCII. IRIs (RFC > 3987) are in Unicode and are accepted by Atom (so, Atom's URIs seem to > be actually IRIs). The standard says: Well, not really the "standard" actually, since the RNC is not normative... ># Unconstrained; it's not entirely clear how IRI fit into ># xsd:anyURI so let's not try to constrain it here >atomUri = text RFC 3987 says (section 1.2 Applicability): For example, XML schema [XMLSchema] has an explicit type "anyURI" that includes IRIs and IRI references. Therefore, IRIs and IRI references can be in attributes and elements of type "anyURI". So, actually, it seems that the Atom RNC could say "atomUri = xs:anyURI". ...or RFC 3987 is wrong... (I didn't check XMLSchema to try to figure it out myself) -- Thomas Broyer
Re: More on atom:id handling
[on atom-syntax only, no need to CC atom-protocol] 2006/2/1, David Powell <[EMAIL PROTECTED]>: > > Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote: > > > > IIRC, it was to allow a feed listing "revisions" of the same entry: > > same id, different "updated" values. > > I don't have a problem with allowing multiple revisions with the same > atom:id in a single document at all; I think that is a good thing. > > On the contrary, I have a problem with preventing multiple revisions > from having the same atom:updated value. It subverts the intent of > atom:updated being a subjective element, and it puts the feed compiler > in an impossible situation. Nothing prohibits the entry author from > producing two different instances with the same atom:updated value, > but given this valid situation, the feed compiler is forced to > silently lose data. […] > It also prevents synchronization applications, such as Microsoft's SSE > from introducing a more discerning date/revision extension, because > nothing is allowed to be more discerning than atom:updated, even > though the specification admits that: > > "not all modifications necessarily result in a changed atom:updated > value" Totally agree. You should add it to http://intertwingly.net/wiki/pie/RFC4287Errata -- Thomas Broyer
Re: More on atom:id handling
[CC'ing atom-syntax] 2006/2/1, David Powell <[EMAIL PROTECTED]>: > > Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote: > > > Entries in an Atom feed can share the same atom:id but their > > atom:updated values should be different. > > To be precise, it is "Entries in an Atom Feed Document" not "Entries > in an Atom feed". > > I really really dislike that rule, and don't understand how it was > ever accepted, and personally I would be tempted to ignore it. IIRC, it was to allow a feed listing "revisions" of the same entry: same id, different "updated" values. -- Thomas Broyer
Re: Browser behaviour
2006/1/30, John Panzer <[EMAIL PROTECTED]>: > > (and if possible click on a link to lead them to the > >site's browser-dedicated pages); those people should just use a > >rel=nofollow" on the "direct links" to their feeds. > > > "I don't think that means what you think it means". At least, if you > mean for search engines not to follow the link. If you just want the > PageRank of the destination feed (?) to be unaffected by the PageRank of > the source URL, then yeah, I guess... Right! How about robots.txt? http://www.robotstxt.org/wc/exclusion.html#robotstxt -- Thomas Broyer
Re: Browser behaviour
> David House wrote: > > 2) Atom support isn't there. Firefox and Konqueror (the browsers I > > tested in) get scared off by Atom's mime type and prompt the user to > > download it. They don't recognise it as XML, so they don't transform > > it. We have two options here: give up or serve as text/xml (I guess > > the latter won't be too popular). Really, browsers should recognise > > application/atom+xml as something they can parse as XML and do so. Why should Atom be "parsed as XML" by browsers? If people fear that users come onto their site through a search engine and arrive on an Atom feed, so they want their feeds to be shown in the browser (in a fancy way if possible) so that users won't be feared and go away (and if possible click on a link to lead them to the site's browser-dedicated pages); those people should just use a rel=nofollow" on the "direct links" to their feeds. So I'd say: - * in the page header for autodiscovery - eventually in the page body to allow users to more easily subscribe in external readers (either via mime-type dispatching or "copy link address"/paste) And, follow those guidelines: http://www.scottfrancis.com/blog/2006/01/21/ui-updates/ * oops, sorry, there's no "type" parameter to the application/atom+xml type… so let's say -- Thomas Broyer
Re: Atom Tombstones Draft
2006/1/27, James M Snell <[EMAIL PROTECTED]>: > >tag:example.org,2006:someentry<--required--> >2005-01-27T12:12:12Z<--required--> >James<--optional--> >comment spam<--optional--> > […] > Is this better? No, because it's not clear whether atom:author and atom:summary were the one of the deleted entry or relative to the deletion. tag:example.org,2006:someentry 2005-01-27T12:12:12Z James comment spam Some will probably have the same question about the atom:updated: is it the date when the entry was deleted or the atom:updated value before deletion? Some will probably ask whether then atom:id is the one of the at:deleted-entry… But now that you're having something looking more and more like an atom:entry, how about just adding an at:deleted to an atom:entry? and integrating the at:by and at:comment inside the pub:control in a more generic way to provide edit comments? (issue: pub:control is specific to the APP) … tag:example.org,2006:someentry … 2006-01-25T10:10:10Z … tag:example.org,2006:someentry … 2006-01-27T12:12:12Z Thomas comment spam The only drawback –a priori– of this solution is that it means updating the atom:updated value of the atom:entry, which will bring the entry to the attention of the user if the reader doesn't support the del:* extension… not really what was intended isn't it? (however, it's arguable: should a deletion be silent? how about adding a del:when in the del:deleted? the atom:updated would then continue to serve its role: whether to bring the entry to the user's attention) Just thinking out loud… -- Thomas Broyer
Re: Atom Tombstones Draft
2006/1/27, James Holderness <[EMAIL PROTECTED]>: > > James M Snell wrote: > > One question: what's a reasonable length of time to keep the deleted-entry > > elements in a feed? We don't really want to keep those things around > > forever. > > Actually I think I probably would recommend keeping them forever. Just treat > them like any other entry. If they fall out the bottom of the feed window > that's ok, but if the server implements next/previous links to history > feeds, then the tombstone could still be found in the archives. […] > Anyway, that's my preference. Not necessarily a SHOULD recommendation - just > my personal opinion. +1 Maybe at:by and at:comment could be used in pub:control in the APP as well -- Thomas Broyer
Re: new draft? (was: invention)
2006/1/21, Anne van Kesteren <[EMAIL PROTECTED]>: > Quoting Thomas Broyer <[EMAIL PROTECTED]>: > > Why not use the "media" attribute? > > Because that would be "tag abuse". No more than using the @rel value (is a feed an alternate for a single-entry HTML page?). So let's change the application/atom+xml media type to add parameters to it: application/atom+xml;kind=feed application/atom+xml;kind=entry application/atom+xml;kind=entry;type=xhtml,audio/mp3 -- Thomas Broyer
Re: new draft? (was: invention)
2006/1/21, Robert Sayre <[EMAIL PROTECTED]>: > > On 1/19/06, 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. I really think autodiscovery shouldn't use the link relation at all: Welcome to my blog My dummy entry Why not use the "media" attribute? If you have feeds dedicated to some media (mainly screen –full content or video enclosures–, handheld –summary-only or title-only, or low-quality enclosures– or aural –audio-only enclosures–), add that media in the comma-separated list: I'm not sure how the comma-separated values should be interpreted in HTML (subscribe OR aural, or subscribe AND aural?), it might be better to replace the previous list values with a single "parameterized" value (e.g. "subscribe audio", "subscribe video", "subscribe text", "subscribe audio video", etc.) -- Thomas Broyer
Re: Is there a bug in undefinedAttribute?
2005/12/1, A. Pagaltzis <[EMAIL PROTECTED]>:
>
> * Uche Ogbuji <[EMAIL PROTECTED]> [2005-12-01 17:55]:
> > Your suggested change would not be incorrect, but it would add
> > no value and be confusing (at least until atom ever decided to
> > have "global" attributes, for some reason).
>
> Confusing, how? Attributes in the Atom namespace are already
> forbidden, unless I'm misreading the following:
>
> 6.2 Extensions To the Atom Vocabulary
>
> The Atom namespace is reserved for future forwards-compatible
> revisions of Atom. Future versions of this specification
> could add new elements and attributes to the Atom markup
> vocabulary. Software written to conform to this version of
> the specification will not be able to process such markup
> correctly and, in fact, will not be able to distinguish it
> from markup error. For the purposes of this discussion,
> unrecognized markup from the Atom vocabulary will be
> considered "foreign markup".
You are misreading. Re-read the last sentence.
> The schema OTOH permits unknown attributes in the Atom namespace
> in undefinedAttribute – whereas it explicitly excludes unknown
> elements in simpleExtensionElement, anyForeignElement and
> friends.
I'd say that anyForeignElement, extensionElement and co. are not
accurate, but correcting them would be a pain (or maybe RelaxNG has
some feature I don't know of): e.g. in atom:entry, extensionElement
should read "any element in non-Atom namespace or any element in Atom
namespace that is not defined as a child of atom:entry by this
specification", and these elements are named "simple extension
element" or "structured extension element" depending on other rules
(not really necessary in the RNC though...) something like:
entryExtensionElement =
entrySimpleExtensionElement | entryStructuredExtensionElement
entrySimpleExtensionElement =
element * - (atomAuthor | atomCategory | ...) {
text
}
...
> So if my reading is correct, the (normative) spec disagrees with
> the (informal) schema. I'd say that is what's confusing.
Your reading was incorrect (w.r.t. my reading ;-) ) but the
(normative) spec effectively disagrees with the (informal) schema.
--
Thomas Broyer
Re: How to specify multiple alternative encodings of the same content?
A. Pagaltzis wrote: > > * J.B. Nicholson-Owens <[EMAIL PROTECTED]> [2005-11-07 06:40]: >> I'd like to be able to tell the user's software that there are >> multiple encodings of the same show, one in Ogg Vorbis, another >> in FLAC, and a third in Speex. > > The basic idea is simple: > > > > > > However, there is currently no mechanism to specify that these > enclosures are all equivalent, and that the client should pick > only one of them. Clients which automatically download closures > will probably take all three. How about: Not really equivalent to [EMAIL PROTECTED]"enclosure"] though -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James Holderness wrote: > > Thomas Broyer wrote: >> As I already explained, paging is orthogonal to the incremental nature >> of a feed. An incremental feed will be chunked as explained in Mark's >> current Feed History draft (just use an atom:[EMAIL PROTECTED]"previous"] >> instead of the fh:prev extension element) and a non-incremental feed as >> described in the OpenSearch result 1.1 draft. > > I beg to differ. I think the incremental state of a feed is very relevant > to paging. If the aggregator does not know that a feed is non-incremental > it will not be able to process the feed document in a meaningful manner. Yes, but that's orthogonal to paging. > And when I say non-incremental I mean something like a "Top 10" list where > the entries in the feed document are a complete replacement for any > entries that the aggregator may have previously received from that feed. I have the same definition. >> What's the difference between a search feed and a non-incremental feed? >> Aren't search feeds one facet of non-incremental feeds? > > Not necessarily, no. A search feed could quite easily be implemented as an > incremental feed. This is the most sensible approach since it would allow > the feed to be viewed in all existing aggregators without requiring a > special knowledge of non-incremental feeds. > > The initial feed document consists of all known results at the time the > search is initiated. As new results are discovered over time, the feed can > be updated by adding new entries to the top of the feed in much the same > way that new entries would be added to the top of a blogging feed. In > fact, if you do a search with something like feedster, this is exactly the > sort of feed you will get back. You're describing the PubSub behaviour, which is not IMO a "search engine" but an aggregator with filtering capabilities. PubSub filters are quite similar to the "category feeds" you see sometimes: "I don't want the whole blog entries, just the ones belonging to that category, or tagged with that word". With PubSub, you say "I don't want the whole web entries, just the one matching that filter". You're not describing a "search feed" (or maybe more a search *result* feed, like OpenSearch result feeds) but a "filtered aggregate feed" (as published by PubSub). >> However, an incremental feed could take advantage of differentiating >> between paging and "archive linking": if linking to archives uses an >> atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to >> point >> at an incremental feed where each entry describes an archived set of >> entries (see [1] for a more detailed example); such a feed has the >> advantage of paging that it allows direct access to a specific point of >> time inside the feed "pages". Each "archived set of entries" could for >> example cover one or two week, so a user could navigate through the >> "feed state" or "feed history" not only by going from pages to pages but >> also by accessing archived chunks via an "index" or "table of contents". > > This is all very interesting, but not possible without more link > extensions which don't exist yet. Wait a bit and I'll propose them for registration. When they'll exist, what would become your argument? > With what we have so far we can do incremental feed archives; we can do at > least some form of searching; we can do non-incremental feeds (of the "Top > 10" variety) with history. I think that's a good start. But we also want paged non-incremental feeds (OpenSearch result feeds), while "non-incremental feeds with history" have not yet proven to be needed. You're trying to describe "incremental feed paging" and "navigation through non-incremental feed snapshots" with the same link relation. When people will want "non-incremental feed paging" (and this is already a need), we'll have two link relations related to paging (for incremental and non-incremental feeds) and one that can also be used to navigate into non-incremental feeds history. Here's a chunked incremental feed (each chunk has 10 entries): 111 21 31 41 51 61 71 81 |||||||||| ^^ `' This is a chunk. present < time -> past previous/next link from chunk to chunk. Entries are added into or before the #1 chunked above. Here's a chunked non-incremental feed (e.g. OpenSearch result feed; each chunk has 10 entries): 111 21 31 41 51 61 71 81 |--
Re: New Link Relations -- Ready to go?
James M Snell wrote: > I'm perfectly happy with leaving previous and next free of any semantics > right now and letting the market sort things out. If more specific link > relations prove to be necessary, then so be it, define the more specific > link relations. If the market can get by with generic links + some kind > of extra flag (e.g. incremental=true, etc) then great. if your case (b) > dies off... that's great too. The point is, let's not over specify this > thing right now; leave it open enough for the market to figure out how > to use it. What are the use cases right now? - Mark's proposed feed state reconstruction - OpenSearch result feeds chunking This is just "paging". What is it also allowing? - publish any non-incremental (i.e. non time-based, like OpenSearch results) feeds chunked in small documents (Top 50 in 5 pages of 10 entries) What is it not covering? - linking between snapshots of non-incremental feeds (last week's Top 50, OpenSearch result of previous query) - linking between different "sites" (i.e. webrings) 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). -- Thomas Broyer
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: However, an incremental feed could take advantage of differentiating between paging and "archive linking": if linking to archives uses an atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed "pages". Each "archived set of entries" could for example cover one or two week, so a user could navigate through the "feed state" or "feed history" not only by going from pages to pages but also by accessing archived chunks via an "index" or "table of contents". Sorry, forgot the link: [1] http://www.imc.org/atom-syntax/mail-archive/msg17308.html -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James Holderness wrote: Thomas Broyer wrote: You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) I see where you're coming from, but this kind of thing is already a problem without even taking links into consideration. For an aggregator to be able to do anything vaguely meaningful with a feed it has to be able to assume that the feed is incremental in nature. As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:[EMAIL PROTECTED]"previous"] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft. The difference is that an incremental feed is sorted by date so the older parts will become more or less "stable" over time; while a non-incremental feed is replaced as a whole each time it is updated, with no other relation to time. When the feed is updated an aggregator will by default assume that any new items can safely be added to the top of an inbox, any updates are updates to existing items, and any removed items have merely "fallen off the bottom" of the feed. However, as soon as we introduce the concept of non-incremental feeds, an aggregator that is not aware of the concept will fail to process such a feed in a meaningful way. We've created a situation where an aggregator has to be aware of the (still to be specified) fh:incremental extension, Microsoft's simple list extensions for RSS, and whatever future extensions may arise; basically the ability to see into the future. This problem merely repeats itself when it comes to processing archives. When we receive a "next" link, ideally we would like to assume it's a pointer to the next archive to be processed. For a regular incremental feed this isn't a problem. Even a search feed could be processed safely if ordered the right way. However, when it comes to non-incremental feeds we're screwed again. I agree that it sucks, but we're already stuck with that situation so I'm not sure that these links will make things any worse. What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? The difference between incremental and non-incremental feeds is that, when dealing with incremental feeds, paging can be seen as a link to archives, as the feed is tightly related to time. When dealing with non-incremental feed, the "previous page" is totally different than the "previous archived snapshot". However, an incremental feed could take advantage of differentiating between paging and "archive linking": if linking to archives uses an atom:[EMAIL PROTECTED]"archives"] (or call it "history" if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed "pages". Each "archived set of entries" could for example cover one or two week, so a user could navigate through the "feed state" or "feed history" not only by going from pages to pages but also by accessing archived chunks via an "index" or "table of contents". -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James M Snell wrote: Thomas Broyer wrote: You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) Ah, didn't see the last question ;-) My choice would be for it to not automatically download 'em. Just present the user with the available links and let 'em follow the ones they want. So you're indirectly telling Mark to either: - continue using an fh:prev extension element - define a more specific link relation (previous-page?) - stop dreaming of an automatic process for feed state reconstruction… I'd rather say: define first/previous/next/last for "paging" only and use them for feed-state reconstruction. If someone wants some other "ordered" relationships, he'll define a new link relation (e.g. webring-previous). Moreover, this is consistent with the OpenSearch start/previous/next/end link relations (where start=first and end=last). -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James M Snell wrote : Thomas Broyer wrote: So you are OK with these feeds: Yes, they all look good to me. You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James M Snell wrote : Thomas Broyer wrote: How would you use these link relations for feed state reconstruction (that is, automatic handling by the Atom processor, without user action –except probably the "please reconstruct this feed's state" action) if you can't know what's pointed at? How would you navigate through a paged search result (e.g. OpenSearch result feed) if previous/next might point at previous/next queries (e.g. history of what people searched for before you) or previous/next pages of the result feed? How would you disambiguate between two "next" link on pointing at the next chunk of a paged feed and the other pointing at the next archived feed? (e.g. "August Top 100, page 2" and "September Top 100") I thought we all agreed that we need a specific definition (related to paging) of these relations and were previously voting about how to call them (previous or prev-archive) I wouldn't disambiguate them as I don't believe it's necessary to. What's needed is a way of identifying the role|purpose|intent of a feed; not a way of disambiguating the links between them. An "archive" feed should be treated differently than a "search" feed which should be treated differently than a "subscription" feed. So you are OK with these feeds: GET /top50.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml Content-Location: /top50/2005/w42/1.atom http://www.w3.org/2005/Atom";> Week #42 Top 50 Top 50 best selling singles http://music.example.net/top50/2005/w42/1.atom"; /> http://music.example.net/top50.atom"; /> http://music.example.net/top50/2005/w41/1.atom"; /> http://music.example.net/top50/2005/w42/2.atom"; /> false … GET /top50/2005/w42/2.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml http://www.w3.org/2005/Atom";> Week #42 Top 50 (11th to 20st) Top 50 best selling singles http://music.example.net/top50/2005/w42/2.atom"; /> http://music.example.net/top50.atom"; /> http://music.example.net/top50/2005/w41/1.atom"; /> http://music.example.net/top50/2005/w42/1.atom"; /> http://music.example.net/top50/2005/w42/3.atom"; /> false … GET /top50/2005/w41/1.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml http://www.w3.org/2005/Atom";> Week #41 Top 50 Top 50 best selling singles http://music.example.net/top50/2005/w41/1.atom"; /> http://music.example.net/top50.atom"; /> http://music.example.net/top50/2005/w40/1.atom"; /> http://music.example.net/top50/2005/w42/1.atom"; /> http://music.example.net/top50/2005/w41/2.atom"; /> false … How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) -- Thomas Broyer
Re: New Link Relations -- Ready to go?
James M Snell a écrit : Thomas Broyer wrote: Mark Nottingham wrote: - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. This definition doesn't prevent someone from using this link relation for linking within a series of documents representing, say a "webring", where "previous" and "next" will be other sites' feeds. I really think we should make it clear that first/previous/next/last are meant for "paging" of a single feed only. I'll try to propose a replacement text. -1. I see no reason to limit this to paging of a single feed. How would you use these link relations for feed state reconstruction (that is, automatic handling by the Atom processor, without user action –except probably the "please reconstruct this feed's state" action) if you can't know what's pointed at? How would you navigate through a paged search result (e.g. OpenSearch result feed) if previous/next might point at previous/next queries (e.g. history of what people searched for before you) or previous/next pages of the result feed? How would you disambiguate between two "next" link on pointing at the next chunk of a paged feed and the other pointing at the next archived feed? (e.g. "August Top 100, page 2" and "September Top 100") I thought we all agreed that we need a specific definition (related to paging) of these relations and were previously voting about how to call them (previous or prev-archive) -- Thomas Broyer
Re: New Link Relations -- Ready to go?
Mark Nottingham wrote: > - Attribute Value: previous > - Description: A URI that refers to the immediately preceding > document in a series of documents. This definition doesn't prevent someone from using this link relation for linking within a series of documents representing, say a "webring", where "previous" and "next" will be other sites' feeds. I really think we should make it clear that first/previous/next/last are meant for "paging" of a single feed only. I'll try to propose a replacement text. > - Attribute Value: subscribe +1 -- Thomas Broyer
Re: General/Specific [was: Feed History / Protocol overlap]
Thomas Broyer wrote: Mark Nottingham wrote: Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" -1, (see James' comments) b) a generic relation, e.g., "previous" +1 Hmm, I might have answered a bit too fast… "previous" might be too generic and thus be used for things other than paging through a feed (would it be incremental –feed reconstruction– or not –search result, etc.), so I'd +1 to "previous-page". On the other hand, if we don't register "previous" now, someone might register it later for something else (don't know what the IESG can approve…), with the same potential misuses… But if we register "archives" or "history" at the same time (or, say, quite early in Atom the 1.0 deployment), misuses (the most common I think, using previous/next for inter-"feed state" linking, e.g. linking from the October Top 100 non-incremental feed to the September Top 100 non-incremental feed) could be prevented… We should then also add a note in the previous/next description telling people not to use them for such things as described earlier, maybe also using the term "page" or "paging" explicitly… As a result, I'm still -1 on prev-archive and +1 on previous, but add a +.75 on "previous-page". -- Thomas Broyer
Re: General/Specific [was: Feed History / Protocol overlap]
Mark Nottingham wrote: Perhaps people could +1/-1 the following options: * Reconstructing a feed should use: a) a specific relation, e.g., "prev-archive" -1, (see James' comments) b) a generic relation, e.g., "previous" +1 -- Thomas Broyer
Re: Feed History / Protocol overlap
Antone Roundy wrote: > On Oct 18, 2005, at 5:13 PM, Robert Sayre 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. > > Ohh, nice readability. Perhaps a few refinements: > > A URI that points to the next in a series of Feed documents, each > representing a segment of the same feed. For example, in a reverse- > chronologically ordered series of Feed documents, the 'next' URI > would point to the document next further in the past. +1, *this* is "paging". We could add another example, e.g. sorted by relevance (within a search result) or priority If you want to link between different "states" of "Top 100" feeds (October, September, August, etc), then use something like @rel="archives" or @rel="history", or define a @rel="previous-archive" if you really want to navigate directly to the other feed without having to go through a "table of contents" feed. If some people here prefers "next-chunk" or "next-page" to just "next", why not, my mind is open -- Thomas Broyer
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
Eric Scheid wrote: 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? I'm not a native English speaker so… …but what's wrong with "archives"? According to my understanding of "archives vs. history", when an Archived Feed (January 2005 Top 100 feed) links to the Archive Feed (the one listing each and every Archived Feed), isn't "history" a bit "disturbing"? as the Archive Feed will contain entries about archives of feeds published later (February 2005 Top 100 feed, March 2005 Top 100 feed), that is, the Archive Feed doesn't contains the "history" of the January 2005 Top 100 feed but "archives" of each Top 100 feed ever published. As said above, English is not my mother tong, so I don't really mind which word is chosen, I'll use it (also, someone other than me will certainly have to go through the IANA registration process, or at least help me to do it…) -- Thomas Broyer
Re: Feed History / Protocol overlap
Robert Sayre wrote: [about the "previous" link relation] A stable URI that, when dereferenced, returns a feed document containing a set of entries that sequentially precede those in the current document. I already have code that uses "next" for this. Why do we want to change it? Er, I'm not a native English speaker, so my apologies in advance if I'm wrong… If a feed is sorted by the entries' atom:updated value in descending order (which AtomPP currently requires for "Lists"), isn't "next" meaning "entries with an atom:updated representing an earlier date-time" (remember, entries are sorted in descending order!) and "previous" meaning "entries with an atom:updated representing a later date-time"? If entries are sorted in descending order, the "first" feed is the one with the greatest values (atom:updated representing now, a second ago, a minute ago, …) and the "last" one the one with the lowest values (atom:updated representing the "oldest" date-times). Hence, in the "first" feed you'll find an atom:[EMAIL PROTECTED]"next"] and in the "last" one an atom:[EMAIL PROTECTED]"previous"]. Conclusion: I think you, Mark and the guys behind OpenSearch all agree… Now I think we should ask the OpenSearch people if they already have requested IANA registration for their start/next/prev/end link relations (hasn't James already asked them?) and if they haven't, then we (the WG) should first agree on the terms to be used (start/end vs. first/last), request registration and tell the OpenSearch people that these relations are pending registration. Any thoughts? -- Thomas Broyer
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
Antone Roundy wrote:
>>> If the complete set represents all the entries ever published
>>> through an ever-changing feed document (what a feed currently is,
>>> you subscribe with an URI and the document you get when
>>> dereferencing the URI changes as a sliding-window upon a set of
>>> entries), then paging allows for feed state reconstruction.
>>> In other terms, feed state reconstruction is a facet of paging, an
>>> application to non-incremental feeds.
>
> Let's say you're doing a feed for the Billboard top 100 songs. Each
> week, the entire contents of the feed are swapped out and replaced by
> a new top 100 (ie. it is a non-incremental feed). And let's say you
> don't want to put all 100 in the same document, but you want to break
> it up into 4 documents with 25 entries each. You now have two
> potential axes that people might want to traverse--from songs 1-25 to
> 26-50 to 51-75 to 76-100, or from this weeks 1-25 to last weeks 1-25
> to two weeks ago's 1-25, etc. You can't link in both directions with
> the same "next".
>
> There are clearly two distinct concepts here--navigating through the
> chunks that make up the current state of the feed resource, and in a
> non-incremental feed, navigating though the historical states of the
> feed resource.
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:
Top 100 feed:
October 2005 Top 100
no
...
Archive feed:
yes
...
September 2005 Top 100
...
August 2005 Top 100
...
...
September 2005 Top 100 feed:
September 2005 Top 100
no
...
--
Thomas Broyer
Re: New Link Relations? [was: Feed History -04]
James M Snell wrote: > > Thomas Broyer wrote: >> Depends whether @rel="self" was really meant for subscribing and the >> spec wording is not precise enough about it; this could then be fixed >> with an errata rather than create a new link relation >> Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) >> or I missed something >> > "self" should always point to the feed document containing the self > link. It makes no sense to have a "self" link in a feed that does not > point to itself. Right, off course My apologies So +0.5 to "subscribe" because it seems to overlap "first" (or "last"?) or I missed something ;o) -- Thomas Broyer
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
Mark Nottingham wrote: > They seem similar. But, what if you want to have more than one paging > semantic applied to a single feed, and those uses of paging don't > align? I.e., there's contention for prev/next? 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. If you want to provide the exact same entries sorted (thus paged) differently, then that's another feed. -- Thomas Broyer
Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]
Mark Nottingham wrote: My concern is that if there is more than one use of a link relation like 'next' or 'prev', those uses could conflict. For example, if I use 'prev' for Feed History, will that cause a problem with feeds using Amazon OpenSearch if they want to use it in a slightly different way? To put it in Thomas' terms, what if there are different concepts of paging using the same terms -- which there seem to be already? I don't think there are different concepts of paging. Paging is navigation through subsets (chunks) of a complete set of entries. If the complete set represents all the entries ever published through an ever-changing feed document (what a feed currently is, you subscribe with an URI and the document you get when dereferencing the URI changes as a sliding-window upon a set of entries), then paging allows for feed state reconstruction. In other terms, feed state reconstruction is a facet of paging, an application to non-incremental feeds. I think it's worth waiting consensus on previous/next or forwards/backwards, first/last or head/tail, etc. and having a "paging" spec (or just IANA registration, I don't really matter), and orthogonally define an fh:incremental extension (fh:incremental will just change newsreaders behavior, not the paging concept). It seems James is having the same feeling… -- Thomas Broyer
Re: New Link Relations? [was: Feed History -04]
Mark Nottingham wrote: - Attribute Value: prev - Description: A stable URI that, when dereferenced, returns a feed document containing entries that sequentially precede those in the current document. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority than the current document). - Attribute Value: next - Description: A stable URI that, when dereferenced, returns a feed document containing entries that sequentially follow those in the current document. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: Because automated agents may follow this link relation to construct a 'virtual' feed, care should be taken when it crosses administrative domains (e.g., the URI has a different authority than the current document). - Attribute Value: first - Description: A stable URI that, when dereferenced, returns a feed document containing those entries furthest preceding those in the current document at the time it was minted. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: - Security considerations: - Attribute Value: last - Description: A stable URI that, when dereferenced, returns a feed document containing those entries furthest following those in the current document at the time it was minted. Note that the exact nature of the ordering between the entries and documents containing them is not defined by this relation; i.e., this relation is only relative. - Expected display characteristics: Undefined. - Security considerations: +0.5 (adding the circular references issue raised by James), because some people will use "first" to link to the "live" feed (the one you subscribe to) and "next" to link to the first archive document and so on, and some will use "last" and "prev" for the exact same roles… The given definition is not precise enough. And wrt "prev", why not "previous"? both could also be registered as aliases… - Attribute Value: subscribe - Description: A stable URI that, when dereferenced, returns a feed document containing the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of changes in the feed. When different from the URI of the feed document it exists in, it indicates a URi that should be used for this purpose in place of the current document's URI. - Expected display characteristics: Undefined. - Security considerations: Users should always be informed of the actual URI they are subscribing to, and subscription should only take place when it is explicitly requested. Depends whether @rel="self" was really meant for subscribing and the spec wording is not precise enough about it; this could then be fixed with an errata rather than create a new link relation… Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) – or I missed something… -- Thomas Broyer
Re: Feed History -04
James M Snell wrote: if I point my newsreader to a feed document that has a incremental=true, I would look for a start link. I would process the start feed then begin walking my way through the next links to build the history. The start feed MAY have the most recent entries or MAY have the oldest entries, it doesn't matter. It does matter if I don't want my newsreader to reconstruct the entire feed state and rather stop when it has read X entries or has reached Y-day old entries. There shouldn't be any requirement that the entries in a feed (or even the feed documents themselves) have to be in a specific order in order to reconstruct the history. It should (not SHOULD!) however be based on atom:updated or something similar (e.g. my-ext:last-modified) -- Thomas Broyer
Re: Feed History -04
Mark Nottingham wrote: I don't want this draft to become the all-singing, all-dancing feed model review; although there's lots of interesting stuff there, it's way too ambitious for my tastes (and I think I detect the smell of a tarpit faintly wafting...). The feed history case gets us to a nice 80+% point; the rest can come in separate vehicles. Any response to 'prev-archive'? Question: is what you want really a link to archives or isn't it just "simple" paging through a feed? I suspect it is the latter, because reconstructing feed state is only needed if a complete set of entries is split into several documents. Therefore, I'll rather suggest moving to: - a spec about paging, defining head/prev/next (do we really need tail?) [note: see with A9/OpenSearch people] - a spec defining fh:incremental, describing relation to paging (can a non-incremental feed be paged? does it mean something different than paging of an incremental feed?) - eventually a spec defining links to archives (which in turn may use paging: think about archives of search results, what did the same query return yesterday, last week, last month, etc.) -- Thomas Broyer
Re: Feed History -04
James Holderness wrote: 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. I think that Mark's concerns were that readers/aggregators generally keep a local history of the feeds they're subscribed to. fh:incremental=no would explicitly tell them not to do so. -- Thomas Broyer
Re: Feed History -04
Mark Nottingham wrote: How about: ? I always thought this was the role of @rel="self" to give the URI you should subscribe to, though re-reading the -11 it deals with "a resource equivalent to the containing element". 1. Isn't "a resource equivalent to the containing element" the same as "an alternate version of the resource described by the containing element"? 2. Is the answer to 1. is no then what does "a resource equivalent …" mean? Is it really different than "the URI you should subscribe to" (at least if @type="application/atom+xml")? -- Thomas Broyer
Re: Feed History -04
Lindsley Brett-ABL001 wrote: I have a suggestion that may work. The issue of defining what is "prev" and "next" with respect to a time ordered sequence seems to be a problem. How about defining the link relationships in terms of time - such as "newer" and "older" or something like that. That way, the collection returned should be either "newer" (more recent updated time) or "older" (later updated time) with respect to the current collection doc. Wouldn't it be "better" to share the same link relations between feeds sorted by date/time or some other "priority" (e.g. OpenSearch results)? -- Thomas Broyer
Re: draft-snell-atompub-feed-thread-01.txt
Byrne Reese wrote: Six Apart is looking to develop an experimental implementation of the Feed Thread extension for Atom. However, I have a few questions: I see this extension as a logical place to list all feedback (both comments and trackbacks). However, I don’t see a way for the extension to differentiate between the two types of feedback an entry may receive. Does anyone know of a way to achieve that? I'd say that « If a comment uses an atom:[EMAIL PROTECTED]"alternate"] or an atom:[EMAIL PROTECTED], it is considered a "remote comment" (similar to trackback/postback). If using atom:link to link to the remote resource, the content might be included in atom:content as well. Remote comments should provide an atom:summary. If a comment has no atom:[EMAIL PROTECTED]"alternate"] and no atom:content/@src, it is a "local comment" (comment added on an entry, similar to "comment submission HTML forms"). Local comments must use atom:content and shouldn't use atom:summary. » (see http://www.imc.org/atom-protocol/mail-archive/msg01384.html for the complete discussion) -- Thomas Broyer
Re: Next and Previous
James Holderness wrote: > Thomas Broyer wrote: >> Compare their atom:[EMAIL PROTECTED]"self" and >> @type="application/atom+xml"]/@href, they'll point you to the "start" of >> the "list", the one whose author and copyright apply. > > On the whole I tend to agree, but since there isn't a "self" link in > either of the RSS formats and Mark would like this extension to be format > neutral, he would either have to introduce an equivalent element into the > spec or strongly suggest that RSS feeds include a "self" atom:link. Maybe one more reason to use an atom:link instead of fh:prev... > Technically it isn't even required that all Atom feeds have such a link, > so either way it's something worth clarifying. Agreed. >> (Actually, author >> and copyright should really appear in "history feed documents" as well, >> aggregators shouldn't "apply copyright" from one document to other >> documents linked from it). > > Technically yes, but try and imagine how an aggregator might handle that > sort of thing. The feed may be made up of a collection of documents, but > from the user's point of view it's all just one big feed. A copyright > message is the sort of thing that would show up once in a properties > dialog for the feed, or somewhere in the header or footer in a "newspaper" > view. Hmm, right. > It's highly unlikely an aggregator would try and track multiple copyright > messages and display them on a per item basis. atom:rights at feed-level don't apply to its entries, just to the feed as it stands. If you want to grant/restrict rights at an entry-level, use the entry-level atom:rights. I can understand how an entry-level atom:rights could be presented to the end-user, but I can't imagine how it could be done for the feed-level atom:rights, given that it can change during the feed's "life". The only solution I can see is to store feed metadata on an atom:source inside each entry, so you can ask for the entry-level and feed-level atom:rights for each entry in your aggregator. > As for author, if you've got item-level author elements you should be ok, > but if there aren't, the aggregator is quite likely to take the last > feed-level author it received and apply it to all subsequent items. It can > be argued that that's a bug, but it's not unreasonable to imagine than > many aggregators might do such a thing unless explicitly told not to. Aggregators are more likely to copy/paste de feed-level authors into each entry and totally forget about feed-level ones. -- Thomas Broyer
Re: Next and Previous
James Holderness wrote: > > Mark Nottingham wrote: >> Probably the closest thing to what you want is this proposal: >> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- >> history-04.txt >> >> It has "previous", but not "next". > > It just occurred to me when reading this message that there may be some > advantages to having a "next" link to go along with the "prev". I realise > you don't need it in order to reconstruct a feed's history, but it does > provide you with a certain amount of validation. For example, it's > possible that someone could create an empty feed with nothing but their > own title, author and copyright messages and a "fh:prev" link to someone > else's feed in order to claim credit for a publication that wasn't their > own. If an aggregator could rely on the existence of a "next" link it > would be able to check for issues like that. Compare their atom:[EMAIL PROTECTED]"self" and @type="application/atom+xml"]/@href, they'll point you to the "start" of the "list", the one whose author and copyright apply. (Actually, author and copyright should really appear in "history feed documents" as well, aggregators shouldn't "apply copyright" from one document to other documents linked from it). If the "borrower" uses an atom:[EMAIL PROTECTED]"self"]/@href different from the one found in history documents, aggregators should issue a warning. They could also dereference the @href and see if they are redirected to the final same URI. If the "borrower" uses the same atom:[EMAIL PROTECTED]"self"]/@href as the one found in history documents, aggregators should subscribe to that URI and not the "borrower"'s one, so the "borrower" can't claim anything. I think atom:[EMAIL PROTECTED]"self"] is sufficient, there's no need for a "next". -- Thomas Broyer
Re: ACE - Atom Common Extensions Namespace
Mark Nottingham wrote: My .02, FWIW, and off the top of my head; I think this is a well-intentioned effort, but at the wrong end of the process. The market (i.e., users and implementors) should have a go at sorting out at what's common/prevalent enough to merit this sort of thing; having a co-ordinated namespace will lead to the problem of what to lump into it, how to version individual extensions within it, etc. In other words, some of the benefits of Namespaces in XML -- e.g., loose coordination, well-insulated name spaces, ability to change namespace without changing local name to effect versioning -- will be lost, all for the sake of saving a few characters. Not worth it, IMO. -1 to ACE, for the very same reasons. -- Thomas Broyer
Re: ACE - Atom Common Extensions Namespace
Martin Duerst wrote: At 07:04 05/10/03, Walter Underwood wrote: > >--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren ><[EMAIL PROTECTED]> wrote: >> >> Having a file and folder of the same name is not technically possible. >(Although >> you could emulate the effect of course with some mod_rewrite.) > >Namespaces aren't files, only names. Yes. But the W3C insists on having an actual file there, just for documentation at least, or ideally for some machine-readable information (schema,...). >Also, some filesystem implementations do allow a file and a folder >with the same name. Yes. The W3C server could certainly be tweaked to allow that, but it would be easier not to have to do that. Hey wake up! If http://www.w3.org/2005/Atom maps to a file system folder, any web server that I know of will send a redirect to http://www.w3.org/2005/Atom/ and "display" the directory index file (index.html, default.htm, etc.) Moreover, there is precedence at w3.org to use URI without a trailing "/" as "public identifiers" (cool URIs?) when they actually are "folders": See the "last version" links to CSS2 and DOM Level 2 recommendations: http://www.w3.org/TR/REC-CSS2 http://www.w3.org/TR/DOM-Level-2-Core http://www.w3.org/TR/DOM-Level-2-HTML http://www.w3.org/TR/DOM-Level-2-Style http://www.w3.org/TR/DOM-Level-2-Views … I really don't understand why you're discussing this sort of thing… We could really have an http://www.w3.org/2005/Atom/extensions namespace. -- Thomas Broyer
Re: FYI: Updated Index draft
James M Snell wrote: Complete example ... priority index order="descending">http://www.example.com/ranking/foo ... C 10 3 http://www.example.com/ranking/foo";>30 […] Thoughts? It looks more and more like Microsoft's RSS simple list extension [1], and I think they had the good approach (define sorts on the feed metadata, based on extension element values at the entry level) but a bad technical solution (use the extension element in a different context: when in cf:sort, it has a non-namespaced data-type attribute and its content is a "label" string, while in an entry it might not have attributes and its value should be of type specified by the @data-type attribute seen before). Suggestions: 1. get rid of your i:rank, users will use any extension element instead (no more registry and you can still define "standard" priority and index extensions) 2. get rid of your @order attribute: users should be able to choose in which order they want their entries: best-ranked to least-ranked "top to bottom" or "bottom to top". Its the responsibility of the producer to provide labels and values that will be well-understood by users (e.g. not saying "stars" and ranking from 1 (best rank) down to 5: "stars" implies "number of stars", so "sort by stars in ascending order" implies "the highest the value, the better it is", which is not what's behind 1=best-rank…) 3. make content of i:raking a user understandable label 4. (optional) add a data-type attribute to i:ranking (maybe rename that one to something related to sorting, not ranking) 5. use @namespace and @localname attributes on i:ranking to describe the element in entries the sort applies to (using those attributes prevent from using QNames in attribute values, which doesn't work great with prefix changes) http://example.com/user-review"; localname="stars">User-reviews stars … http://example.com/user-review";>1 … This, however, doesn't match "index" in the draft title any more. What could be even better, though a lot less "simple" (and not feasible, see below), would be to use XPath or XPointer (XPointer has the advantage that you define namespace prefix bindings "inside" it , using the xmlns() XPointer scheme). That way, you could use any element/subelement and/or attribute as the value holder for the sort. This would require however an XPath/XPointer engine, as well as storing the XML DOM, or mapping XPath/XPointer to your internal feed representation; this is not feasible. [1] http://msdn.microsoft.com/windowsvista/building/rss/simplefeedextensions/ -- Thomas Broyer
Re: "Top 10" and other lists should be entries, not feeds.
Bob Wyman wrote: I’m sorry, but I can’t go on without complaining. Microsoft has proposed extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are proposing much the same for Atom (i.e. stateful, incremental or partitioned feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds. It seems to me that if you want a “Top 10” list, then you should simply create an entry that provides your Top 10. Then, insert that entry in your feed so that the rest of us can read it. If you update the list, then just replace the entry in your feed. If you create a new list (Top 34?) then insert that in the feed along with the “Top10” list. Henry Story also proposed atom:id to be "order-related": http://www.w3.org/2005/Atom";> ... tag:first-in-list Some entry ... tag:second-in-list Another entry ... and a bit later: http://www.w3.org/2005/Atom";> ... tag:first-in-list Another entry ... tag:second-in-list Yet another entry ... Note how tag:first-in-list entry now represents "Another entry" while it were previously "Some entry", and tag:second-in-list now is "Yet another entry" while it were "Another entry". -- Thomas Broyer
Re: Feed History -03
Mark Nottingham wrote: > For that matter, if Henry's interpretation were correct, the element > could be > >./archives/archive1.atom > > And Atom processors would magically know that XML Base applies to the > URI therein. It's the magic that I object to; inferring the > applicability of context based on the presence or absence of other > markup isn't good practice, and will lead to practical problems. E.g., > what if I want to have an optional attribute on an empty > element? Is it "simple" or "complex"? FYI, I already rose this up in late May [1]. That was before format-09... [1] http://www.imc.org/atom-syntax/mail-archive/msg15863.html -- Thomas Broyer
Re: Updated Comments Draft (getting closer)
James M Snell wrote: The simple answer is that not everything I may want to reply too will have an ID I can reference. Suppose that what I'm responding to is an item in an RSS feed that does not contain a guid element? All I have to go off of is the URL of the RSS feed or the RSS item's link element... neither of which are actual ID's. From your draft's abstract: This memo presents a mechanism that allows feeds publishers to express threading relationships between entries and feeds. And from your draft's introduction section: This document specifies a mechanism that allows the expression of threaded discussions within the Atom Syndication Format ([I-D.ietf- atompub-format]). As I read it, your proposal is about enabling threading in Atom to allow aggregators to present entries in a tree form. If you want to comment on a non-Atom resource, create a new link/@rel value or use a [EMAIL PROTECTED]"related"] or [EMAIL PROTECTED]"via"] or something like that. So a strong +1 to making the id REQUIRED. -- Thomas Broyer
Re: Atom error pages
Graham wrote: It's far too late for this, but how should Atom servers produce/ clients deal with error pages? Feedster regularly changes its search results feed to a single entry "Search results temporarily offline" feed document (RSS guid "http://www.feedster.com/";), and I think served with HTTP status 200. This seems the wrong behavior for so many reasons. What should they be doing in Atom? Graham I think there are two cases here: * when publishing Atom feeds or entries through HTTP, an HTTP error code with an Atom body is fine (at least for me). As far as aggregator behavior is concerned, I think they could show the entry as part of the feed but discard it as soon as the feed can be retrieved without error. * when using the Atom Publishing Protocol's POST or PUT, it might be worth defining an error document type to tell the client why its document has been refused (e.g. POSTing an Atom Entry with a base64-encoded MSWord content and the server only accepts the three "basic" content types; or an Atom Entry with more than one category to a server supporting only one category per entry; or using an extension "control information" not supported by the server: it should be able to tell the client which one has been refused; etc.) -- Thomas Broyer
Re: Latest on the comments extension
James M Snell wrote: > >>>/in-reply-to provides the atom:id (not dereferencable) of an >>>original atom:entry and may appear within atom:feed or >>>atom:entry. in-reply-to on the feed level indicates that all >>>of the entries within the feed are considered replies to the >>>identified atom:entry. >>> >>> >> >>Is it legal if it appears at both levels? And what does it mean >>then? >> >> >> > Yes. If the entry level link has the same URI as the feed level link, > there is no effect... it's basically just redundant data. If the entry > level link specifies a different URI, then it's basically an assertion > that the entry is a response to two different entries. If all of the > entries within a feed are replies to the same entry, putting the > in-reply-to at the feed level simply gives you a shortcut the same way > that putting atom:author elements at the feed level rather than entry > level does. > > e.g. > > 1. > > > > > > > > > 2. > > > > > > > > > 3. > > > > > > > #2 is not how atom:author "inheritance" works (assuming there is some kind of atom:author inheritance, which is not established). I'd prefer #2 to be equivalent to this: That is, the set of entry level links overrides the set of feed level links. If I understand correctly, ".../root" tells you where to find the entry identified with ".../in-reply-to". How are you dealing with multiple in-reply-to? If I misunderstood, what is ".../root" for? -- Thomas Broyer
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Antone Roundy wrote: > > On Wednesday, July 20, 2005, at 11:44 AM, Thomas Broyer wrote: >> I was actually wondering why non-stateful feeds couldn't have >> archives: in the "This month's Top 10 records" feed, why couldn't I >> link to "Last month's Top 10 records"? >> If this kind of links are not dealt within feed-history, then I >> suggest splitting the draft into two (three) parts: >> 1. fh:stateful: whether a feed is stateful or not >> 2. fh:prev: state reconstruction of a stateful feed >> 3. (published later) fh:: link to archives of a non-stateful >> feed >> (no, I actually don't want such a split, I'd rather deal with the "3." >> in feed-history, no matter how) >> >> If we want to solve this "issue" using a distinct element (fh:prev if >> fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still >> needed? The presence of fh:prev would be equivalent to >> fh:stateful=true, >> the presence of fh: would be equivalent to fh:stateful=false, the >> absence of both fh:prev and fh: would be equivalent to the absence >> of fh:stateful, and the presence of both fh:prev and fh: would be >> an >> error. >> This is off course true only if fh:prev must be accompanied by >> fh:stateful=true. The question is: is it useful to have fh:stateful if >> you have no link to any kind of archive? >> > I would think that rather than fh:stateful="true | false", it might be > more useful to have (with a different element name, and perhaps > different values) fh:what-kind-of-feed-is-this="sliding-window | > snapshot | ???". If it's a sliding-window feed, fh:prev points to the > previous sliding window. If it's a snapshot feed, then fh:prev points > to the previous snapshot. fh:what-kind-of-feed-is-this might have a > default value of sliding-window. +1 and with the addition of fh:prev/@updated (and an optional fh:prev/@title, see below), it turns feed-history to a really cool extension! We could also add some more hints about fh:prev processing depending on fh:what-kind-of-feed-is-this: * if the value is "sliding-window", an Atom Processor MAY reconstruct the feed state automatically without user interaction * if the value is "snapshot", an Atom Processor SHOULD NOT retrieve archive snapshot feeds unless told by the user (e.g. showing a link or button using fh:prev/@title as the label); when presented to the user, entries in the retrieved snapshot feed SHOULD replace any entry from within another snapshot (e.g. "Last Month's Top 10 records" should replace "This Month's Top 10 records"). fh:prev/@title could be used on sliding-window feeds to indicate the title of the latest entry in the previous feed (just like blog homepages sometimes link to the previous entry using its title). fh:prev would look like: http://example.net/archives/june.atom -- Thomas Broyer
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
This mail has been around in my drafts folder for about 10 days, but here it is... I'm not sure what my position is wrt what I wrote below... Mark Nottingham wrote: On 04/07/2005, at 6:18 PM, Thomas Broyer wrote: With the -01 draft (it might have been the same within the -00 one too), one can't reuse the process to link to archives of "Top Twenty Records" or "Most Popular Items" (e.g. a monthly "Top Twenty Records" linking to the previous-month "Top"), because of the "a subscription document whose fh:stateful element contains "false" MUST NOT contain a fh:prev element". Why not just stating that if fh:stateful is false then the "prev"- linked archive feed doesn't not contain a subset of the previous entries but rather does contain the previous state of the subscription feed. I.e. the meaning of the fh:prev "link" depends on the value of fh:stateful. That's interesting, but it somewhat changes the semantics of "prev"; it goes from "where you can find previous entries in a logical feed" to "where you can find an older archive of entries." While these are often the same thing, it might not always be the case; i.e., someone might want to publish a non-time-based feed. So, I'm nervous about having two different semantics for one element, depending upon its context of use. I fully understand (that's actually also somehow bothering me). I was actually wondering why non-stateful feeds couldn't have archives: in the "This month's Top 10 records" feed, why couldn't I link to "Last month's Top 10 records"? If this kind of links are not dealt within feed-history, then I suggest splitting the draft into two (three) parts: 1. fh:stateful: whether a feed is stateful or not 2. fh:prev: state reconstruction of a stateful feed 3. (published later) fh:: link to archives of a non-stateful feed (no, I actually don't want such a split, I'd rather deal with the "3." in feed-history, no matter how) If we want to solve this "issue" using a distinct element (fh:prev if fh:stateful=true, fh: if fh:stateful=false), is fh:stateful still needed? The presence of fh:prev would be equivalent to fh:stateful=true, the presence of fh: would be equivalent to fh:stateful=false, the absence of both fh:prev and fh: would be equivalent to the absence of fh:stateful, and the presence of both fh:prev and fh: would be an error. This is off course true only if fh:prev must be accompanied by fh:stateful=true. The question is: is it useful to have fh:stateful if you have no link to any kind of archive? I also repeat my proposal for an identifier different from an URI for a reader/aggregator to know whether it has already retrieved an archive document, e.g. using the "updated" date-time of the "fh:prev"-linked archive feed. Example: http://purl.org/atom/ns#draft-ietf-atompub-format-09"; xmlns:history="[TBD]"> Example Feed http://example.org/"/> 2003-12-13T18:30:02Z John Doe urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 true http://example.org/2003/11/index.atom Atom-Powered Robots Run Amok http://example.org/2003/12/13/robots_here"/> urn:uuid:1225c695-cfb8-4ebb--80da344efa6a 2003-12-13T18:30:02Z Some text in a new, fresh entry. If I retrieved the feed between 2003-11-24T12:00:00Z and 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http:// example.org/2003/10/index.atom (october, not november). However, I didn't miss any entry. Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry and that I then don't need to dereference http://example.org/ 2003/11/index.atom (november, the "new" fh:prev URI) Hmm, that seems awfully complex (and hard to grasp -- but maybe it's just me :) just to avoid a round trip. One, or a few more... depending on how you archive your entries (daily archive document, weekly archive document, N entries per archive document, etc.), how you publish your entries in the subscription feed (N entries in the feed, or only those entries published during the N last days), and who frequently you post. Your subscription feed entries can overlap several archive feeds and the fh:prev jump from "archive2.atom" to "archive5.atom". Using "updated", you can avoid 3 round trips in that case. ...or too many: what if I switch URL addressing scheme (e.g. from "archive1.atom"..."archiveN.atom" to "2005/January.atom"..."2005/June.atom")? A "dumb" reader will retrieve back every archive feed, as it has never ever dereferenced the URIs. That 'proba
Re: More while we're waiting discussion
James M Snell wrote:
Ok, distilled from this conversation...
1. Comments can either be included directly within the feed or in a
separate feed.
2. Comment entries are distinguished by a link @rel="in-reply-to"
@href="{$original-entry/atom:id}"
As an atom:id is an identifier that might (should?) not be
"dereferenceable", atom:link is not a good choice. An extension element
whose content is an URI/IRI (similar to atom:id) would be better:
{$original-entry/atom:id}
3. Comment feeds may be indicated using a link @rel="comments"
@href="{$comment-feed-url}" as a child of
3. Comment feeds may be indicated using a link @rel="comments"
@href="{$comment-feed-uri}". If used as a child of atom:feed, it links
to a feed containing all comments on all entries. If used as a child of
atom:entry, it links to a feed containing only the comments on the entry.
Example 1: Entries and comments in a single feed
http://example.com/2
http://example.com/1";
...
http://example.com/1
...
Example 2: Comments in a separate, associated feed
http://example.com/comments.xml"; />
http://example.com/1
http://example.com/1/comments.xml";
title="Comments on this entry" />
http://example.com/2
http://example.com/1
...
The in-reply-to link could also be used in feeds that are not directly
associated with the source feed. e.g. if you post an entry in your
blog and I post a reply to that entry in my blog. My entry can use
the in-reply-to link so that thread aware readers can make the
connection appropriately.
Your entry should also link to a representation of the "commented
resource" using an atom:[EMAIL PROTECTED]"related"].
And if you're relaying information, you could use an
atom:[EMAIL PROTECTED]"via"], as proposed in
http://www.intertwingly.net/wiki/pie/PaceLinkRelVia
Question: could the @rel="comments" link be handled appropriately
using the existing @rel="related"? The question hinges on whether or
not it is semantically important to distinguish "comments" from other
types of related entities. I'm not convinced it is. If a
@link="related" points to an Atom feed, who cares what that feed
contains, the user agent can make the feed available for the user to
subscribe to pulling in the relevant entries.
I don't know yet...
--
Thomas Broyer
Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Mark Nottingham wrote: This draft is based on comments received; thanks to everyone. Major changes; * Removed 'this' link * Changed link syntax * Changed stateful syntax * Clarified difference between 'subscription' and 'archive' feeds (note that they're just for the purposes of clarity in this spec) * Added a bit to the state reconstruction process description * Added examples Really good work! Comments and suggestions welcome as always, Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, true and false. With the -01 draft (it might have been the same within the -00 one too), one can't reuse the process to link to archives of "Top Twenty Records" or "Most Popular Items" (e.g. a monthly "Top Twenty Records" linking to the previous-month "Top"), because of the "a subscription document whose fh:stateful element contains "false" MUST NOT contain a fh:prev element". Why not just stating that if fh:stateful is false then the "prev"-linked archive feed doesn't not contain a subset of the previous entries but rather does contain the previous state of the subscription feed. I.e. the meaning of the fh:prev "link" depends on the value of fh:stateful. Also, shouldn't there be a note to invite producers to provide an atom:[EMAIL PROTECTED]"self" referencing the subscription feed? I also repeat my proposal for an identifier different from an URI for a reader/aggregator to know whether it has already retrieved an archive document, e.g. using the "updated" date-time of the "fh:prev"-linked archive feed. Example: http://purl.org/atom/ns#draft-ietf-atompub-format-09"; xmlns:history="[TBD]"> Example Feed http://example.org/"/> 2003-12-13T18:30:02Z John Doe urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 true http://example.org/2003/11/index.atom Atom-Powered Robots Run Amok http://example.org/2003/12/13/robots_here"/> urn:uuid:1225c695-cfb8-4ebb--80da344efa6a 2003-12-13T18:30:02Z Some text in a new, fresh entry. If I retrieved the feed between 2003-11-24T12:00:00Z and 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http://example.org/2003/10/index.atom (october, not november). However, I didn't miss any entry. Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry and that I then don't need to dereference http://example.org/2003/11/index.atom (november, the "new" fh:prev URI) -- Thomas Broyer
Re: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Antone Roundy wrote:
> Getting back to how to use static documents for a chain of instances,
> that could easily be done as follows. The following assumes that the
> current feed document and the archive documents will each contain 15
> entries.
>
> The first 15 instances of the feed document do not contain a "prev"
> link (assuming one entry is added each time).
>
> When the 16th entry is added, a static document is created containing
> the first 15 entries, and a "prev" link pointing to it is added to the
> current feed document. This link remains unchanged until the 31st entry
> is added.
>
> When the 31st entry is added, another static document is created
> containing the 16th through 30th entries. It has a prev link pointing
> to the first static document. The current feed document's prev link is
> updated to point to the second static document, and it continues to
> point to the second static document until the 46th entry is added.
>
> When the 46th entry is added, a third static document is created
> containing the 31st through 45th entries, etc.
However, there should then be a "this" link in the "live" feed, otherwise
I'll have to retrieve (as a reader/aggregator) the "prev" feed each 15
entries:
Say I retrieved the feed when it was 15-entries long. When the 16th entry
is added and the first static document created, the "live" feed is added a
"prev" link, pointing to a document I never retrieved, so I guess I might
have missed entries and retrieve it. I end up retrieving back the 15
entries I already know of.
When the 31st entry is added, the feed's "prev" link is changed to
reference the new 16th-to-31st archive feed. This is an URI I never
dereferenced, so I guess I might have missed some entries and then
dereference the URI and retrieve the archive feed. If I had retrieved the
feed when it was 30-entries long, I end up retrieving back the 16th to
31st entries I already know of.
One could argue that I don't need to retrieve the archive feed as the live
feed already contains 14 entries (2nd to 15th, or 17th to 30th) I already
retrieved, using atom:updated and atom:id to notive them.
Well, nothing precludes an entry to be "pushed to front" even if its
atom:updated hasn't changed, so the entry following such a "puished to
front" entry could be one I never saw and I might have missed it.
And actually, this doesn't otherwise change the problem, which would still
arise if I retrieve the "live" feed when, say, it was 15-entries long and
15 entries later: I never saw the "prev" archive feed or any of the 15
entries in the "live" feed (so I can't conclude anything based on
atom:id+atom:updated), I then retrieve the "-prev" linked archive feed and
end up retrieving 15 entries I already know of, because it happens than I
actually didn't miss any entry between my two "live" feed retrievals...
So we need a mean to either identify the *next* "prev" link (a "this" or
"permalink" link in the "live" feed (no need to have one in "archive"
feeds, as already said on the list), which means it must be predictable),
or something to tell us we didn't missed entries, such as the atom:updated
of the "prev"-linked archive feed (is atom:updated enough?).
We'll end up with the "live" feed being either:
http://example.com/2005/05/"; />
http://example.com/2005/06/
...
or
http://example.com/2005/05/";
fs:updated="2005-05-31T23:59:59" />
...
One advantage of the latter is that you don't rely on URIs as identifiers
for the feed archive documents and they can be moved/split/merged without
readers and aggregators being then implicitly told to retrieve back the
whole archives (if you change URIs, they'll think they missed entries...).
--
Thomas Broyer
Re: FWD: I-D ACTION:draft-nottingham-atompub-feed-history-00.txt
Dave Pawson wrote: > Any one site could now have n instances, each being a feed, the only > variant (apart from entries) being the links to previous feeds. > If I'm to say *this* is my feed, I guess I point to the most recent... > which will change over time? > > With the example of 15 entries per, > > feed1 1..15 > feed4 45..60 > > my 'feed' for my site rolls over from feed1...n as time progresses? I guess the answer is: http://example.com/latest is your feed, e.g. containing the latest 10 entries http://example.com/archive-1 through n are your "archive" feeds. "latest" is likely to contain entries which are also "archived" in "archive-n", but I don't see it as a problem (and it doesn't violate Atom Feed Document rules wrt uniqueness of entries), at most I will retrieve 14 entries (if using 15 entries per "archive feed document") which I already got from the "live" feed. You can see "latest" as an Atom alternate for your home page (or latest news page) and "archive-1" through "archive-n" as Atom alternates for your "archive" pages. What I'm wondering is, if I had "archive feeds" on a per-day basis (instead of "N entries per archive feed", although what follows also applies) and say I published 3 entries yesterday, 5 entries the day before and no entry yet today: - http://example.net/archive/2005/06/27: 5 entries - http://example.net/archive/2005/06/28: 3 entries - http://example.net/archive/2005/06/29: doesn't exist yet Say I'm having a "live feed" showing the latest 5 entries: it will contain all the 3 yesterday entries and the 2 latest entries from 2005/06/27. Could I "prev"-link to "archive/2005/06/28" or should I try to figure out the "archive feed" containing the "previous to earliest" entry (here, "archive/2005/06/27", but it could have been "archive/2005/06/25" if I had only 2 entries last monday and not at all on sunday) ? If I can just link to the "latest archive feed document", shouldn't we then just have an "archive" [EMAIL PROTECTED] in the "live feeds" (similar to the "List-Archive" header in mail messages) and use "prev" only between "archive feed documents" (similar to the "Next Page" link in the HTML list archive). -- Thomas Broyer
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Mark Baker wrote: Martin, The general idea seems to be that conversion to HTML is good for human consumption with a browser, and for human navigation in an archive. message/rfc822 is the original, and may be very good for reuse in a mailer (e.g. for replying), except that mailers don't support it much at the moment. http://www.example.org/lists/list/archive/12345"/> Unfortunately, that's bad Atom. Section 4.1.3.1 of the format spec says; On the atom:content element, the value of the "type" attribute MAY be one of "text", "html", or "xhtml". Failing that, it MUST be a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [MIMEREG]). If the type attribute is not provided, Atom Processors MUST behave as though it were present with a value of "text". where "composite type" is defined to be multipart/* and message/*. If the intent of that restriction was to avoid the whole non-XML attachments issue, then it seems to have failed to account for the use of the "src" attribute to include the data by reference rather than by value. I'm sorry that I didn't notice this earlier. 8-( Er, and it seems there's another (related) problem: In 4.1.3.1: [ If the type attribute is not provided, Atom Processors MUST behave as though it were present with a value of "text". ] Just below, in 4.1.3.2: [ If the "src" attribute is present, the "type" attribute SHOULD be provided and MUST be a MIME media type [MIMEREG], rather than "text", "html", or "xhtml". ] So what if I provide a "src" attribute but no "type" attribute? The "type" attribute would "default" to "text", but "text" is forbidden if "src" is provided... I suggest that if src is provided but not type, there is no "type value", as this value is just advisory and not authoritative. However, if src is not provided (the content is local), processors must "behave as though it were present with a value of text". -- Thomas Broyer
Re: OpenSearch RSS
Tim Bray wrote: Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting to hear substantial buzz around this thing. I wonder, is embedding the OpenSearch RSS stuff in Atom going to cause any heartburn? I'm inclined to think not, but would appreciate others having a look. I get the feeling that OpenSearch + Atom could be real useful. -Tim Just to see how it would look like, this is what the search result example [1] would be in Atom: http://a9.com/-/spec/opensearchrss/1.0/";> A9.com Search: New York City history tag:A9.com,2005:New%20York%20City%20history http://a9.com/New%20York%20City%20history"; /> Search results for "New York City history" at A9.com © 2003-2005, A9.com, Inc. or its affiliates. A9.com, Inc. http://a9.com/ 2005-05-30T23:50:00+02:00 423 1 10 New York City History http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html"; /> http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html 2005-05-30T00:00:00+02:00 ... Harlem.NYC - A virtual tour and information on businesses ... with historic photos of Columbia's own New York neighborhood ... Internet Resources for the City's History. ... Gotham Center for New York City History http://www.gothamcenter.org/"; /> http://www.gothamcenter.org/ 2005-05-30T00:00:00+02:00 ... Submit Events Edit Your Submission. Main Neighborhood Stories NYC History in the ... The Gotham Center for New York City History is supported by The CUNY Graduate ... Welcome to the Museum of the City of New York http://www.mcny.org/"; /> http://www.mcny.org/ 2005-05-30T00:00:00+02:00 ... a list with the event staff. Additional information will be included in the confirming email. © Museum of the City of New York. Some comments: * I set type="text/html" on the feed's alternate link, because the OpenSearch RSS 1.0 Specification [1] says the RSS is "a URL that can recreate the search in HTML format", @type is not used in entries as it might not be text/html * I changed the escaped-HTML © to ©, it saves us an internal DTD subset while allowing us to use type="text" * Atom mandates an atom:author, I added a dummy one * Atom mandates an atom:updated in the feed, I added a dummy one; it should be set to the latest atom:updated date found in the feed's entries, or at least to the date the request was made. * Atom mandates an atom:updated in each entry, I added a dummy one; it should be set to the last access of the search engine to the "result document", or eventually the date the request was made. For example, Google is able to give you this date if it has cached the document (when you look at a cached page, Google puts a "this is Google's cache of as retrieved on " on top of the page. * I used the address of the "result document" (permalink?) as the atom:id of each entry, because this is the easiest way to do it... I've put this document online [2], with the "Atom 0.3" namespace URI (http://purl.org/Atom/ns#) Note that the OpenSearch RSS 1.0 Specification [1] forbids the use of escaped HTML in many elements. If there were an "OpenSearch Atom", it could also be limited to type="text" (and/or type="xhtml", because it's quite easy to transform XHTML to plain text), though A9.com website (which acts as an reader/aggregator for OpenSearch RSS documents) would then not be a valid Atom Processor. The OpenSearch Description Document [3] would /a priori/ be the same (except of course that it would use a different value in the "Format" element to indicate "OpenSearch Atom" instead of "OpenSearch RSS". The Atom result document could also link to the next and previous "pages" with additional atom:link elements in the atom:feed, with "extended" @rel values. [1] http://opensearch.a9.com/spec/opensearchrss/1.0/ [2] http://www.ltgt.net/atom/opensearch.atom [3] http://opensearch.a9.com/spec/opensearchdescription/1.0/ -- Thomas Broyer
Re: Problem with Metadata Elements (section 6.4)
David Powell wrote: > > Quoting Thomas Broyer: > >> The problem come when I use a "plain flowed text" and can then omit >> the "type" attribute: >> By Thomas Broyer and al. >> My extension becomes a Simple Extension Element when processed by an >> Atom Processor, and an Atom Processor having some "generic support" >> for Simple Extension Elements (which is really the intent of SEE) >> would change its behavior when processing it, which is not really >> wanted. >> However, I don't think I badly designed the byline extension, or this >> would imply that Atom itself is badly designed (and I don't think so). > > I don't think that this is a big problem. The allowed syntax of > Structured Extension Elements is defined by the designer of the > Structured Extension. It is the designer's responsibility to ensure > that Structured Extensions don't flip into being Simple Extensions, so > they need to be designed in a way such that they have at least one child > element or attribute. > > In this case the easiest way to do this would be to make @type mandatory > even when @type="text" is required. Of course yes, but the extension then doesn't follow the same rules as Text Constructs, which are part of Atom, and it's bothering me. If I can't design my extensions in the same way Atom designed its markup, I think there is a problem... That's why I think the Metadata Elements (Simple and Structured Extension Elements) wording is too strong in the spec. The intent is (should be) to give a hint to Atom implementors providing generic support for "name/value pair" properties and to extension designers, not to enforce a particular behavior. Changing that would also throw away your problem (discussed offlist) with later allowing (e.g. in Atom 1.1) Metadata Elements in Atom elements where foreign markup is today just "foreign markup", without any defined role. To summarize for other people on the list, David's problem was that if we don't define a role today for foreign markup inside Atom elements other than atom:feed, atom:entry, Person Constructs and atom:source, e.g. inside atom:link, then we wouldn't be able to define it later, because foreign markup that would have been used with Atom 1.0 don't necessarily follow the rules of section 6.4 and therefor won't be ok if Atom 1.1 says that atom:link's foreign markup children are now considered Metadata Elements. -- Thomas Broyer
Problem with Metadata Elements (section 6.4)
I was discussing extensions offlist with Dave Powell and came to explain what I previously said on the list about Simple/Structured Extension Elements [1] when I thought I found a real problem with that. There have been much discussion last weeks about authors, contributors and bylines and bylines were rejected to extensions (and I'm +1 on that, that's not the point). So imagine I want to create such a byline extension. Ideally, I'd like it to be text that can be enriched with some markup. The obvious choice here is to reuse the Text Construct mechanism: it is already implemented in every Atom Processor so adding support for my byline extension would be made much easier than redefining a different mechanism, and of course it is homogeneous with Atom so better for users. So my ext:byline element MAY have a "type" attribute with value "text", "html" or "xhtml". When not present, it defaults to "text". Depending on the "type" attribute's value, the content is "plain flowed text", escaped HTML or an XHTML div. My byline extension then looks like the following, and is obviously a Structured Extension Element (as it comes in atom:feed, atom:entry or atom:source): By Thomas Broyer and al. By <a href="http://www.ltgt.net/";>Thomas Broyer</a> and al. By http://www.ltgt.net/";>Thomas Broyer and al. The problem come when I use a "plain flowed text" and can then omit the "type" attribute: By Thomas Broyer and al. My extension becomes a Simple Extension Element when processed by an Atom Processor, and an Atom Processor having some "generic support" for Simple Extension Elements (which is really the intent of SEE) would change its behavior when processing it, which is not really wanted. However, I don't think I badly designed the byline extension, or this would imply that Atom itself is badly designed (and I don't think so). Are other people here seeing a problem with Simple vs. Structured Extension ELements or am I the only one? [1] http://www.imc.org/atom-syntax/mail-archive/msg15751.html -- Thomas Broyer
