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 link rel=self .../ 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: base within HTML content
2007/1/1, Geoffrey Sneddon: On 1 Jan 2007, at 16:59, Asbjørn Ulsberg wrote: the base 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 base 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 DIV 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 div element. -- 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: 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. co-chair-modeIn 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./co-chair-mode Just in case: yeah what Bob said ;-) -- 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 link rel=stylesheet type=text/css href=/style.css / and not link rel=alternate type=text/css href=/style.css / 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 a in the body of the page, where actually it uses no rel= at all). So why the hell is it using rel=alternate? (in a link in the head 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 a and area had a default value (let's say rel=related), then this value could be used in the required rel= attribute of link when linking to feeds which are neither rel=alternate or rel=feed (with the definition given above, *not* the one from HTML5): link rel=related href=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 article 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: link rel=feed href=/feed.atom type=application/atom+xml;type=feed link rel=feed href=/ type=text/html which tells you the page believes it is an item in the linked feeds. Then , in /feed.atom: atom:link rel=alternate href=/ type=text/html / and in the /: link rel=alternate href=/feed.atom type=application/atom+xml;type=feed 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: link rel=contents href=/toc.html type=text/html link rel=contents href=/toc.opml type=what's the media type for OPML? 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: 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: link rel=alternate type=application/atom+xml href=entry.xml / 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: 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: 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: 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: 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: link rel=alternate type=application/atom+xml 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: 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: atom:content type=image/svg+xml.../atom:content 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 atom:content type=xhtml/ (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: object data=where/is/stored/the/entry/content type=image/svg+xml pIf 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:/p p...entry's summary.../p /object pa href=where/is/stored/the/entry/content hreftype=image/svg+xmlDownload the entry content.../a/p 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 link rel=alternate href=... / 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
[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 category scheme=http://my.scheme.net/my-vocabulary/; term=http://my.concept.net/my-vocabulary/13745; label=cats / -- 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 category 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
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 category scheme='http://www.tbray.org/ongoing/What/' term='Places' / 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? category scheme=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 entry ... category scheme='http://www.tbray.org/ongoing/What/' term='Places' / /entry 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: 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 atom:link/ 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: link rel=next href=http://example.com/; type=application/atom+xml action=POST parameter name=q xxx:Payload/ /parameter parameter name=blah value=blah/ /link 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: Language Negotiation
2006/7/27, James M Snell: And within feed documents in the form of language-qualified alternate links (e.g., link rel=self hreflang=fr href=... /, link rel=self hreflang=de href=... /, etc) You rather meant link rel=alternate hreflang=fr type=application/atom+xml href=... / link rel=alternate hreflang=de type=application/atom+xml href=... /, 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 link rel=self/ would have been so much cleaner… …or maybe at least rather a link rel=live / or link rel=subscribable /, 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: 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, 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 entry/ document), asking for a different language? You mean, sending an Accept-Language request-header? 406 Not Acceptable or return the entry even if it does not match the accepted languages. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7 -- Thomas Broyer
Re: Language Negotiation
2006/7/27, Eric Scheid: what would happen if you used conneg on the @rel='self' link (to the entry/ document), asking for a different language? You mean, sending an Accept-Language request-header? 406 Not Acceptable or return the entry even if it does not match the accepted languages. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7 so, do not return the requested language alternate? Hmm, sorry, I think I didn't correctly understood you first question... ...at least I don't understand the second... -- 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 category scheme='http://www.tbray.org/ongoing/tag/' term='Java' somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' / and other item with category scheme='http://www.tbray.org/ongoing/tag/' term='Java' somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' / 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/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: 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: 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: 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/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: 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: 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: [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: 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:
r:values minimum=1.0 maximum=4.0 origin=0.3 steps=1.0 /
r:values minimum=1.0 maximum=4.0 origin=1.3 steps=1.0 /
r:values minimum=1.3 maximum=4.0 steps=1.0 /
r:values minimum=1.3 maximum=3.3 steps=1.0 /
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:
r:values minimum=1.0 maximum=4.0 origin=3.3 steps=-1.0 /
r:values minimum=1.0 maximum=4.0 origin=0.3 steps=1.0 /
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:
!-- The rank value 1 --
r:values origin=1 /
Could be expressed as:
r:value value=1 / !-- a ew r:value element --
or
r:values value=1 /!-- a new value attribute --
or with the following r:values:
r:values minimum=1 maximum=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 in-reply-to id=... / to in-reply-to ref=... / ? +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: link rel=replies href=comments.html type=text/html thr:count=5 / link rel=replies href=comments.atom type=application/atom+xml thr:count=10 / 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 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
[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: 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: 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: - link rel=whatever type=application/atom+xml; type=feed /* in the page header for autodiscovery - eventually a rel=nofollow/a 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 link rel=alternate type=application/atom+xml / -- 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: 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: Atom Tombstones Draft
2006/1/27, James M Snell [EMAIL PROTECTED]: at:deleted-entry atom:idtag:example.org,2006:someentry/atom:id--required-- atom:updated2005-01-27T12:12:12Z/atom:updated--required-- atom:authoratom:nameJames/atom:name/atom:author--optional-- atom:summarycomment spam/atom:summary--optional-- /at:deleted-entry […] 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. at:deleted-entry atom:idtag:example.org,2006:someentry/atom:id atom:updated2005-01-27T12:12:12Z/atom:updated at:byatom:nameJames/atom:name/at:by at:commentcomment spam/at:comment /at:deleted-entry 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) !-- before deletion, in APP context -- atom:entry atom:title…/atom:title atom:idtag:example.org,2006:someentry/atom:id atom:summary…/atom:summary atom:updated2006-01-25T10:10:10Z/atom:updated atom:link rel=edit href=… / /atom:entry !-- after deletion -- atom:entry atom:title…/atom:title atom:idtag:example.org,2006:someentry/atom:id atom:summary…/atom:summary !-- the atom:updated is the date of the deletion, as it's unlikely that the entry will change after that -- atom:updated2006-01-27T12:12:12Z/atom:updated del:deleted del:byatom:nameThomas/atom:name/del:by del:commentcomment spam/del:comment /del:deleted !-- the [EMAIL PROTECTED]edit] has disappeared -- /atom:entry 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: 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: titleWelcome to my blog/title link rel=alternate type=application/atom+xml href=feed.atom title=Subscribe to the Atom Feed / titleMy dummy entry/title link rel=start type=text/html href=/ title=This blog's home page / link rel=start type=application/atom+xml href=feed.atom title=Subscribe to this blog's Atom Feed / link rel=alternate type=application/atom+xml href=dummy.atom / Why not use the media attribute? link rel=whatever type=application/atom+xml href=feed.atom media=subscribe / link rel=whatever type=application/rdf+xml href=feed.rdf media=subscribe / 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: link rel=whatever type=application/atom+xml href=articles.atom media=subscribe / link rel=whatever type=application/atom+xml href=videos.atom media=subscribe, screen / link rel=whatever type=application/atom+xml href=audio.atom media=subscribe, aural / 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: 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: 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: link rel=enclosure type=audio/mpeg href=show.mp3 / link rel=enclosure type=application/ogg href=show.ogg / link rel=enclosure type=audio/x-speex href=show.spx / 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: content type=audio/mpeg src=show.mp3 / link rel=alternate type=application/ogg href=show.ogg / link rel=alternate type=audio/x-speex href=show.spx / Not really equivalent to [EMAIL PROTECTED]enclosure] though -- Thomas Broyer
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?
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 |||||||||| ^^ `' This is a chunk. ++ - relevance -- -- previous/next link from chunk to chunk. Here are non-chunked non-incremental feeds (e.g. Top 10 feeds with history): 1 || - Oct. 24 Top 10 1 || - Oct. 17 Top 10 1 || - Oct. 10 Top 10 previous/next would link from snapshot to snapshot ?! And finally, here are chunked non-incremental feeds (e.g. Top 50 feeds with history, each chunk has 10 entries): ++ -- ranking --- -- 111 21 31 41 51 61 71 81
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?
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 feed xmlns=http://www.w3.org/2005/Atom; titleWeek #42 Top 50/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w42/1.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #41 Top 50 href=http://music.example.net/top50/2005/w41/1.atom; / link rel=next title=Week #42 Top 50 (11th to 21st) href=http://music.example.net/top50/2005/w42/2.atom; / fh:incremental xmlns:fh=…false/fh:incremental … GET /top50/2005/w42/2.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml feed xmlns=http://www.w3.org/2005/Atom; titleWeek #42 Top 50 (11th to 20st)/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w42/2.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #41 Top 50 href=http://music.example.net/top50/2005/w41/1.atom; / link rel=previous title=Week #42 Top 50 (1st to 10th) href=http://music.example.net/top50/2005/w42/1.atom; / link rel=next title=Week #42 Top 50 (21st to 31st) href=http://music.example.net/top50/2005/w42/3.atom; / fh:incremental xmlns:fh=…false/fh:incremental … GET /top50/2005/w41/1.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml feed xmlns=http://www.w3.org/2005/Atom; titleWeek #41 Top 50/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w41/1.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #40 Top 50 href=http://music.example.net/top50/2005/w40/1.atom; / link rel=next title=Week #42 Top 50 href=http://music.example.net/top50/2005/w42/1.atom; / link rel=next title=Week #41 Top 50 (11th to 21st) href=http://music.example.net/top50/2005/w41/2.atom; / fh:incremental xmlns:fh=…false/fh:incremental … 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 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?
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: 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: 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: 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: 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: feed xmlns... titleOctober 2005 Top 100/title fh:incremental xmlns...no/fh:incremental !-- this links to the next chunk of the non-incremental feed -- link rel=next type=application/atom+xml href=26-50.atom title=26 to 50 entries / !-- this links to a list of archives -- link rel=archives type=application/atom+xml href=../archives.atom title=Top 100 archives / ... Archive feed: feed xmlns... fh:incremental xmlns...yes/fh:incremental !-- this links to the next chunk of the archive feed -- link rel=next type=application/atom+xml href=archives2.atom / ... entry titleSeptember 2005 Top 100/title content type=application/atom+xml src=2005/09/1-25.atom / ... /entry entry titleAugust 2005 Top 100/title content type=application/atom+xml src=2005/08/1-25.atom / ... /entry ... September 2005 Top 100 feed: feed xmlns... titleSeptember 2005 Top 100/title fh:incremental xmlns...no/fh:incremental !-- this links to the next chunk of the non-incremental feed -- link rel=next type=application/atom+xml href=26-50.atom title=26 to 50 entries / !-- this links to a list of archives -- link rel=archives type=application/atom+xml href=../archives.atom title=Top 100 archives / ... -- 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: 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: 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: 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: 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: Feed History -04
Mark Nottingham wrote: How about: atom:link rel=subscription href=.../ ? 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: 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: 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
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: 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: FYI: Updated Index draft
James M Snell wrote: Complete example feed ... i:ranking default=yes order=descendingpriority/i:ranking i:ranking order=ascendingindex/i:ranking i:ranking order=descendinghttp://www.example.com/ranking/foo/i:ranking entry ... idC/id i:rank scheme=priority10/i:rank i:rank scheme=index3/i:rank i:rank scheme=http://www.example.com/ranking/foo;30/i:rank /entry […] 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) feed ext:sort data-type=number namespace=http://example.com/user-review; localname=starsUser-reviews stars/ext:sort … entry ur:stars xmlns:ur=http://example.com/user-review;1/ur:stars … 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: feed xmlns=http://www.w3.org/2005/Atom; ... entry idtag:first-in-list/id titleSome entry/title ... /entry entry idtag:second-in-list/id titleAnother entry/title ... /entry /feed and a bit later: feed xmlns=http://www.w3.org/2005/Atom; ... entry idtag:first-in-list/id titleAnother entry/title ... /entry entry idtag:second-in-list/id titleYet another entry/title ... /entry /feed 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 fh:history nonsense=1./archives/archive1.atom/fh:history 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: 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.
!-- legal but redundant --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url1} /
/entry
/feed
2.
!-- equivalent to #3 below --
feed
link rel=.../in-reply-to href={url1} /
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
3.
!-- equivalent to #3 below --
feed
entry
link rel=.../in-reply-to href={url1} /
link rel=.../in-reply-to href={url2} /
/entry
/feed
#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:
feed
entry
link rel=.../in-reply-to href={url2} /
/entry
/feed
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?
link rel=.../root href=feeda.xml /
link rel=.../root href=feeda.xml /
link rel=.../in-reply-to href=tag:entry1 /
link rel=.../in-reply-to href=tag:entry2 /
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: fh:prev updated=2005-06-30T23:55:30 title=Last Month's Top 10 records http://example.net/archives/june.atom/fh:prev -- 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: ?xml version=1.0 encoding=utf-8? feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-09; xmlns:history=[TBD] titleExample Feed/title link href=http://example.org// updated2003-12-13T18:30:02Z/updated author nameJohn Doe/name /author idurn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6/id history:statefultrue/history:stateful !-- added an updated attribute with tha atom:updated value of the http://example.org/2003/11/index.atom document. -- history:prev updated=2003-11-24T12:00:00Z http://example.org/2003/11/index.atom/history:prev entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/robots_here/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated summarySome text in a new, fresh entry./summary /entry /feed 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 'probably' is also worrying me. I used probably because you
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:
thread:in-reply-to{$original-entry/atom:id}/thread:in-reply-to
3. Comment feeds may be indicated using a link @rel=comments
@href={$comment-feed-url} as a child of feed /
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
feed
entry
idhttp://example.com/2/id
thread:in-reply-tohttp://example.com/1; /thread:in-reply-to
...
/entry
entry
idhttp://example.com/1/id
...
/entry
/feed
Example 2: Comments in a separate, associated feed
feed
link rel=comments href=http://example.com/comments.xml; /
entry
idhttp://example.com/1/id
link rel=comments href=http://example.com/1/comments.xml;
title=Comments on this entry /
/entry
/feed
feed
entry
idhttp://example.com/2/id
thread:in-reply-tohttp://example.com/1/thread:in-reply-to
...
/entry
/feed
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: ?xml version=1.0 encoding=utf-8? feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-09; xmlns:history=[TBD] titleExample Feed/title link href=http://example.org// updated2003-12-13T18:30:02Z/updated author nameJohn Doe/name /author idurn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6/id history:statefultrue/history:stateful !-- added an updated attribute with tha atom:updated value of the http://example.org/2003/11/index.atom document. -- history:prev updated=2003-11-24T12:00:00Z http://example.org/2003/11/index.atom/history:prev entry titleAtom-Powered Robots Run Amok/title link href=http://example.org/2003/12/13/robots_here/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated summarySome text in a new, fresh entry./summary /entry /feed 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: feed xmlns=... xmlns:fs=... link rel=archive href=http://example.com/2005/05/; / !-- I didn't use a link construct as the document not yet exists) -- fs:predicted-archive-uri http://example.com/2005/06/ /fs:predicted-archive-uri ... /feed or feed xmlns=... xmlns:fs=... !-- I used an extension attribute, even if it's not clearly defined by the Atom Syndication Format -- link rel=prev href=http://example.com/2005/05/; fs:updated=2005-05-31T23:59:59 / ... /feed 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. atom:content type=message/rfc822 src=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
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): ext:byline type=textBy Thomas Broyer and al./ext:byline ext:byline type=htmlBy lt;a href=http://www.ltgt.net/;Thomas Broyerlt;/a and al./ext:byline ext:byline type=xhtml divBy a href=http://www.ltgt.net/;Thomas Broyer/a and al./div /ext:byline The problem come when I use a plain flowed text and can then omit the type attribute: ext:bylineBy Thomas Broyer and al./ext:byline 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
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: ext:bylineBy Thomas Broyer and al./ext:byline 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
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: atom:feed xml:lang=en-us xmlns:atom=...Atom NS... xmlns:os=http://a9.com/-/spec/opensearchrss/1.0/; atom:titleA9.com Search: New York City history/atom:title atom:idtag:A9.com,2005:New%20York%20City%20history/atom:id atom:link rel=alternate type=text/html href=http://a9.com/New%20York%20City%20history; / atom:subtitleSearch results for New York City history at A9.com/atom:subtitle atom:rights#169; 2003-2005, A9.com, Inc. or its affiliates./atom:rights atom:author atom:nameA9.com, Inc./atom:name atom:urihttp://a9.com//atom:uri /atom:author atom:updated2005-05-30T23:50:00+02:00/atom:updated os:totalResults423/os:totalResults os:startIndex1/os:startIndex os:itemsPerPage10/os:itemsPerPage atom:entry atom:titleNew York City History/atom:title atom:link rel=alternate href=http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html; / atom:idhttp://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html/atom:id atom:updated2005-05-30T00:00:00+02:00/atom:updated atom:summary... 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. .../atom:summary /atom:entry atom:entry atom:titleGotham Center for New York City History/atom:title atom:link rel=alternate href=http://www.gothamcenter.org/; / atom:idhttp://www.gothamcenter.org//atom:id atom:updated2005-05-30T00:00:00+02:00/atom:updated atom:summary... 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 .../atom:summary /atom:entry !-- ... -- atom:entry atom:titleWelcome to the Museum of the City of New York/atom:title atom:link rel=alternate href=http://www.mcny.org/; / atom:idhttp://www.mcny.org//atom:id atom:updated2005-05-30T00:00:00+02:00/atom:updated atom:summary... a list with the event staff. Additional information will be included in the confirming email. copy; Museum of the City of New York./atom:summary /atom:entry /atom:feed Some comments: * I set type=text/html on the feed's alternate link, because the OpenSearch RSS 1.0 Specification [1] says the RSS link 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 amp;copy; to #169;, 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 URI as retrieved on DATE 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: extension elements inside link elements?
David Powell wrote: IF, the interpretation of Section 6, that Thomas Broyer has helped me to hammered out is correct, then: Extension Elements [6.4], in Atom 1.0, are allowed only as direct children of atom:entry, atom:feed, Person Constructs, and atom:source. They must be qualified with a namespace, and it mustn't be the atom namespace. Note that this kind of extension elements (foreign markup appearing in atom:feed, atom:entry, Person Constructs, and atom:source) is called Metadata Elements, because Atom states such extensions provide additional metadata to their container element (or more accurately additional metadata to the to the resource represented by the container element). Extension Elements, atom:content, and atom:link/@rel are the only User Extensions to Atom. No (for the definition of Extension Elements you gave above). Atom allows foreign markup anywhere in an Atom document. Foreign markup is made of extension elements and extension attributes (i.e. anything not in the Atom namespace, except unprefixed attributes on Atom-namespaced elements). Atom doesn't define the role/interpretation of foreign markup except for those elements appearing in atom:feed, atom:entry, Person Constructs and atom:source, which it defines as Metadata Elements carrying additional metadata about their container element. Future versions of Atom [6.2] may add additional elements to the Atom namespace, may add attributes (namespaced or otherwise) to existing Atom elements, If attributes are namespaced and the namespace is not the Atom namespace, they obviously are foreign attributes (at least for me). and presumably may allow text inside Atom elements (basically any markup that isn't in the spec or an Extension Element). (Text as a 6.2 element isn't mentioned, but it probably ought to be treated as 6.2 by clients.) I think that later allowing just text inside an Atom element would prove a design flaw... At least, it should be made clear that an Atom 1.0 Processor MUST ignore text as a child of an element which Atom doesn't define as allowing text. (er, am I clear?) -- Thomas Broyer
Re: Editorship announcement
Eric Scheid wrote: On 27/5/05 4:14 AM, Tim Bray [EMAIL PROTECTED] wrote: protocol-04 btw, where can we find it? Replace format-08 with protocol-04 and you get it ;o) http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt There's also a link to the last version from http://intertwingly.net/wiki/pie/FrontPage Discussions go on [EMAIL PROTECTED] -- Thomas Broyer
Re: extension elements inside link elements?
David Powell wrote: I'm also a bit confused about the terminology in Section 6.3: It might be the case that the software is able to process the foreign markup correctly and does so. Otherwise, such markup is termed unknown foreign markup. So unknown foreign markup is foreign markup that software is unable to process? Yes, something in a namespace that is not understood by the Atom Processor. But then 6.3 goes on to explain how to process it. This sounds like a contradiction? No, why? Say I am an Atom Processor and I find these extensions elements: !-- defined before: xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; -- geo:lat26.58/geo:lat geo:long-97.83/geo:long Is this something I know how to process? * yes: this is known foreign markup, I process it * no: this is unknown foreign markup, I ignore it without failing or signaling an error Also, in what cases would software be able to process foreign markup other than by ignoring it as described in section 6.3 or treating it as a 6.4 extension? Treating it as a 6.4 extension *is* processing it as described in section 6.3. There is no other case (this is technically implied by section 6.4, see below) So I don't see how the term foreign markup and unknown foreign markup are any different? unknown foreign markup is the subset of foreign markup that an Atom Processor ignores because it doesn't know what do do with it (i.e. how to process it). Also, if 6.4 extensions are a subset of unknown[?] foreign markup, 6.4 extensions are not a subset of foreign markup or unknown foreign markup. 6.4 extensions are the whole foreign markup set (except it doesn't deal with foreign attributes, but the whole section 6 and the whole spec doesn't deal with them). If you read carefully the section 6.4, you'll notice that what is not a Simple Extension Element is a Structured Extension Element. A Simple Extension Element is an element with no attribute and is either empty or has text-only content. A Structured Extension Element is an element with at least an attribute or a child. These are Simple Extension Elements: my:ext/ my:ext/my:ext my:extfoo/my:ext These are Structured Extension Elements: my:ext attr=val / my:ext attr=val/my:ext my:ext attr=valfoo/my:ext my:ext attr=valfoo:bar//my:ext my:ext attr=valbazfoo:bar/baz/my:ext my:extfoo:bar//my:ext my:extbazfoo:bar/baz/my:ext Is there any other construct I missed? -- Thomas Broyer
Re: extension elements inside link elements?
David Powell wrote: Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote: Say I am an Atom Processor and I find these extensions elements: !-- defined before: xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; -- geo:lat26.58/geo:lat geo:long-97.83/geo:long Is this something I know how to process? * yes: this is known foreign markup, I process it * no: this is unknown foreign markup, I ignore it without failing or signaling an error So known 6.4 extensions are known foreign markup, and unknown extensions are unknown foreign markup? Ok. Yes, though known foreign markup is not used in the spec (or I missed it). And actually, you're right (see below) saying 6.4 extensions do not describe the whole foreign markup set (see below). 6.4 extensions are not a subset of foreign markup or unknown foreign markup. 6.4 extensions are the whole foreign markup set 6.2 says that new elements and attributes can be added. 6.2 deals with the Atom vocabulary, which is the markup in the Atom namespace or un prefixed attributes on Atom-namespaced elements (this is my interpretation, it's not clearly stated in the spec, and I'm quite sure I already raised this in the past two weeks). 6.1 deals with foreign markup, that is (still not clearly stated by the spec text) markup in a namespace different from the Atom namespace. Earlier discussion in this thread suggested that these may be inside atom:link elements. Isn't this a type of markup that isn't a 6.4 extension? 6.4 extensions can only appear in atom:feed, atom:entry, and Person constructs. [BUG ALERT - they should blatantly be allowed inside atom:source too, and the inheritance needs explaining] You're right, 6.4 extensions are the subset of foreign markup known as Metadata Elements, they' do not represent the whole foreign markup set. For the people who were proposing that atom:link shouldn't ban content, can they tell me which type of Section 6 markup they regard it to be? Or were they proposing that Section 6.4 should be extended to allow Link Extensions. If future versions of Atom adds (unprefixed) attributes or (Atom-namespaced) elements inside atom:link, they will be Extensions to the Atom Vocabulary per section 6.2. If someone defines extensions (attributes or elements in a namespace other than the Atom namespace) inside atom:link, they will be Extensions From Non-Atom Vocabularies, per section 6.1. As they won't match section 6.4 criteria (not inside atom:feed, atom:entry or a Person Construct), they won't be Metadata Elements and thus their role is undefined (per section 6.4, last sentence of the single 6.4 paragraph). (except it doesn't deal with foreign attributes, but the whole section 6 and the whole spec doesn't deal with them). Yes it does, section 6.2 says that future versions of Atom can add new attributes. You're right. Although you should have refered to section 6.1. Their role is just undefined by the spec. If you read carefully the section 6.4, you'll notice that what is not a Simple Extension Element is a Structured Extension Element. A Simple Extension Element is an element with no attribute and is either empty or has text-only content. A Structured Extension Element is an element with at least an attribute or a child. Yep, I understand Section 6.4, but these rules only apply directly inside atom:entry, atom:feed, and Person constructs [and atom:source]. Foreign markup in other places isn't 6.4 markup, so what is it? It is just foreign markup, per section 6.1. Its role is undefined by the spec. What the spec says is only how to process it (the MustIgnore in section 6.3). Markup which the section 6.2 deals with is markup inside the Atom namespace. It is not foreign markup, though it must be considered as such by Atom 1.0 Processors for the purposes of this discussion. If it matches 6.4 criteria, it is Metadata Elements markup, otherwise, it is just Atom markup which is considered foreign markup for the purposes of this discussion. I must however agree that the spec is not as clear as it could be... it doesn't for example clearly define Atom Vocabulary on which definition of foreign markup is relying. -- Thomas Broyer
Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 15:15]: A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. [...] If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. That seems to allow entries with contributors, but no author. You need to be more precise. It doesn't: I didn't say I'd remove the following bullets ;o) in 4.1.1: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. and 4.1.2: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) I think this clearly demonstrates why I opted for disallowing atom:contributor in absence of ../atom:author: it is difficult to explain. You need a lot of prose to express it. You also need more code and more grammar rules. To me, that raises flags that it’s too complex. Actually, only the first paragraph addresses the author/contributor grouping. The second one might still be necessary to disambiguate the entry - (source XOR feed) inheritance mechanism. Btw, had you seen the above bullet in 4.1.1 doesn't allow for a feed with only imported entries (with atom:source) to be author-less? The following feed is invalid per the current draft: atom:feed xmlns:atom=...Atom NS... atom:entry atom:source atom:authoratom:name.../atom:name/atom:author ... /atom:source ... /atom:entry /atom:feed -- Thomas Broyer
Re: some small comments on 08
Bill de hÓra wrote: Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away unconvinced then. Can you present some arguments to back those opinions up? As you're quoting the reliable implementation sentence, let's start with some code and pseudo code to demonstrate PaceOptionalXhtmlDiv is reliably implementable: With a pull parser (.NET XmlReader, or DOM), using recursivity: function getContent(nodelist) returns nodelist if nodelist.length = 1 then # a single element var element = nodelist[0] if element is xhtml:div and not(element has attributes) then # the single element is a discardable xhtml:div # apply the same function on its children (recursivity) return getContent(element.children) else return nodelist end if else return nodelist end if end function ... The above function would be called like this: if element is atom:content and [EMAIL PROTECTED]xhtml then content = getContent(element.children) end if With a rule-based processor (XSLT), only accounting here for atom:content: !-- The following template applies a different processing whether it finds a discardable XHTML div or not. When you find a discardable XHTML div, you have to apply templates to finds subsequent discardable XHTML div inside that div. -- xsl:template name=process-xhtml-content xsl:choose xsl:when test=count(node()) = 1 and xhtml:div[not(@*)] !-- discardable XHTML div, apply template -- xsl:apply-templates / /xsl:when xsl:otherwise !-- here, we just copy the content -- xsl:copy-of select=node() / /xsl:otherwise /xsl:choose /xsl:template !-- The following template matches any Text Construct or atom:content with @type=xhtml. -- xsl:template match=(atom:content|atom:title|atom:subtitle|atom:summary) [EMAIL PROTECTED]'xhtml'] xsl:call-template name=process-xhtml-content / /xsl:template !-- The following template matches any XHTML div with no attribute which is the only child node of a Text Construct or an atom:content or xhtml:div element. The XSLT transform author have to ensure this template never matches a node in another context (e.g. if he applies templates to the XHTML real content. -- xsl:template match=(atom:content|atom:title|atom:subtitle|atom:summary|xhtml:div) /xhtml:div[not(@*) and count(../node()) = 1] xsl:call-template name=process-xhtml-content / /xsl:template Btw, from what I found in the archives for the last two months (approximately), it seems that what bothers you is less the optional div than linking Atom to XHTML or even more generally use XML in XML. You're asking for some more arguments, have you read Re: Consensus call on last raft of issues [1]? I'm open to discussion if you have a problem with something particular in my proposal, but actually, without some hint, it'd be hard for me to find other arguments. You were pointing the case where a div is deemed necessary, I explained in [1] that a div (without attribute and without sibling) has no meaning and is never necessary. If it is necessary in the application processing the Atom document, it's the responsibility of that application to add it. If it is necessary in the application producing the Atom document and this one has no mean to strip it, the Pace allows this application to put that div in the Text Construct or atom:content, it just says that such a div has no more meaning than the Atom element containing it (that is, grouping its content altogether) and thus will be discarded by the Atom Processor at the other end of the chain. Note that I'm open to change the MUST discard into a SHOULD, as there is no real need for this discarding. Actually, that Pace wouldn't have been necessary if people wanting to produce prefix-free feeds weren't bothered adding a dummy div to achieve their taste and having it become part of the content. The only reason for PaceOptionalXhtmlDiv beyond that, is for interoperability in the Atom Publishing Protocol: the producer of the Atom document (the client when doing a POST or PUT, the server when doing a GET) is free to add as many dummy divs like that without the consumer considering them part of the content. Thus, the following would be OK: Client: PUT ... HTTP/1.1 ... entry xmlns=...Atom NS... ... content type=xhtml !-- I'm using a dummy div because I want prefix-free documents. -- div xmlns=http://www.w3.org/1999/xhtml; Blabla /div /content ... /entry Server: HTTP/1.1 200 OK ... atom:entry xmlns:atom=...Atom NS... xmlns=http://www.w3.org/1999/xhtml; ... atom:content type=xhtml Blabla /atom:content ... /atom:entry In the same way we prevent
Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]: Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. I think of these things in terms of what is possible to express. a) Any entry always has an author. Right, I forgot that. Actually, I was reading the format-08 inlined RNC, which doesn't include the schematron rules. Could there be some improvement to the spec? b) A feed may or may not have an author. c) An entry may or may not have contributors. d) A feed may or may not have contributors. Any solution must not prevent any of these from being expressible. I already discussed why replacement is preferrable to merging when any of these are given at both the feed and entry level. Now with that in mind, c) and d) suggest to me that atom:feed/atom:contributor never inherits to entries. If entries were to inherit from the feed, then in a feed with contributors it is not possible to express that an entry had no contributors. Not if you consider the group formed by the authors and contributors. Hmm, what about that: feed level contributors cascade to the entry level only when there is an atom:author element at the feed level which also cascades. Er, I might be not quite clear, so let's see examples: how would you interpret the following? a) feed: author: A contributor: B entry: no author not contributor b) feed: author: A contributor: B entry: author: C c) feed: author: A contributor: B entry: contributor: C d) feed: contributor: A entry: author: B contributor: C e) feed: contributor: A entry: author: B Other cases don't have any problem (or I missed it) or are invalid (e.g. no author at all) a) The entry inherits both the author and contributor from the feed. b) The entry inherits nothing from the feed. c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. d) The entry inherits nothing from the feed. e) The entry inherits nothing from the feed. Let's see what others have to say about this and then find the appropriate wording. So in summary: The set of atom:entry/atom:author overrides the set of atom:feed/atom:author for a particular entry, should the set be non-empty. [Inheritance with replacement semantics.] The set of atom:feed/atom:contributor applies only to the feed and not to any of its entries. [No inheritance.] I'm not opposed to that but it might not be obvious in the a) example above. -- Thomas Broyer
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Norman Walsh wrote:
Look at the content model for entry: it's a bag o' stuff some of which
is required and some of which is optional (and optionally repeatable)
and it's all allowed to occur in any order.
I've forgotten the details of XSD's support for content models, but
I'm pretty sure that's beyond them.
From XML Schema Part 1 : Structures (Second Edition), section 3.8.1 The
Model Group Schema Component [1]:
(all) contain all and only exactly zero or one of each element specified
in {particles}. The elements can occur in any order. In this case, to
reduce implementation complexity, {particles} is restricted to contain
local and top-level element declarations only, with {min occurs}=0 or 1,
{max occurs}=1.
[1] http://www.w3.org/TR/xmlschema-1/#Model_Group_details
--
Thomas Broyer
Re: inheritance issues (was: Author and contributor)
A. Pagaltzis wrote: * Thomas Broyer [2005-05-24 09:05]: c) feed: author: A contributor: B entry: contributor: C [...] c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. [...] The rule you propose for contributor semi-inheritance is hard to explain clearly in prose and somewhat convoluted to implement in code though. And while I have not gotten around to learning RELAX NG, it also seems that it would be non-trivial to express as any form of grammar. After looking at all these cases, I would instead suggest that we prohibit atom:contributor in absence of an atom:author at the same level. That would make all of c), d) and e) invalid. Note that the semantics you propose for c), d) and e) are still expressible, they just require more repetition. Effectively, I am proposing: A non-empty set of atom:entry/atom:author overrides any set of atom:feed/atom:author and atom:feed/atom:contributor. atom:contributor may only appear if ../atom:author is also given. If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) Actually, the proposed rule is the same as having an atom:person element with a role property (attribute or child element) and a rule which says: A non-empty set of atom:entry/atom:person overrides any set of atom:feed/atom:person. And you replace everywhere in spec atom:author with atom:person with a role equal to 'author' and atom:contributor with atom:person with a role equal to 'contributor'. Please note that I am not proposing changing atom:author and atom:contributor to atom:person with a role property. This is just to make clearer my proposal of considering atom:author's and atom:contributor's as a whole, not atom:author's in one hand and atom:contributor's in the other hand. That seems like it would isolate the specification of atom:contributor from any inheritance issues, whose discussion could be confined to the specification of atom:author. We're talking about authors and contributors but inheritance is to be explicitly defined for (copy)rights, categories, etC. as well. The only constellation that would have been possible with your proposed set of restrictions, which my set of restrictions no longer allow, is expressing that feed has only contributors, but no authors. If anyone feels that such feeds must be expressible, then the restrictions could be loosened so that only atom:entry/atom:contributor requires an ../atom:author; however, as long as noone feels that way, I suggest that the restriction be symmetric to simplify specification and implementation. -0 to forbidding contributors without author at the feed level. -- Thomas Broyer
Re: some small comments on 08
Graham wrote: On 24 May 2005, at 9:40 am, Henri Sivonen wrote: On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on http://www.intertwingly.net/wiki/pie/ PaceOptionalXhtmlDiv. -1, and additionally I don't think the Pace is even complete or reliably implementable. FYI, it is not, and I already explained in which extent (first, I forgot to say in the Pace that the same would apply for atom:content with type=xhtml), that's why I pointed to a mail with some more explanation [1]. I was told not to edit the Pace to reflect it, so... [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer
Re: some small comments on 08
Asbjørn Ulsberg wrote: On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: * 4.2.2 The atom:category Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example. Minor flaw. It happens. I think you are rushing things too fast. It would be much better if we fixed this. I agree. +1, drop the label attribute and make its value a child of the atom:category element. Some more wording would also be needed to explain the exact role of the term attribute. Couldn't its value default to the label when not present (this imply making it optional)? Can't we name them consistently? I'd suggest 'href' or 'url'. Nope. Too late. And this. +2. I have no opinion about atom:uri, it seems find to me but I'm not attached to it. @href gives an Hypertext REFerence to another, related, resource (alternate, related, self, feed, etc.), so -1 to changing its name. @src tells the Atom Processor where the content of the entry is located. I wouldn't be opposed to href in this case, but nothing else than href or src. Other listed examples were about attribute vs. text node, I'm +0.5 to moving text nodes into attributes (in atom:logo and atom:icon) These are also common usages in many XML dialects (XHTML, XInclude, XLink, SVG, etc.) Many of these tend to use XLink when linking to or embedding external resources, so using XLink wouldn't bother me either (hey, some are talking about replacing atom:author|atom:contributor with Dublin Core, so why not?) -- Thomas Broyer
Re: some small comments on 08
Thomas Broyer wrote: Graham wrote: -1, and additionally I don't think the Pace is even complete or reliably implementable. FYI, it is not, Oops, before it'd be misinterpreted: * the Pace is not *complete* * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. -- Thomas Broyer
Re: inheritance issues
Antone Roundy wrote: On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been rejected by the WG. I'm torn on whether to bring this up (I'd like to see it done, but it's getting late), but looking at the reasons given for rejecting PacePersonRef [1][2][3], recent discussion of author, contributor and inheritance suggests that the opposition may have been mistaken. See also [4]. I wasn't there at the time PacePersonRef was proposed. Here's what I'd have said if I were: -1 to dropping inheritance mechanism, this leads to repetitions of atom:author and atom:contributor in each entry +1 to id references as a way to allow factorization of people on one place and thus saves some bytes by preventing the repetition of the Person metadata (it might reveal even much better later when there will be extensions to the Person constructs, e.g. FOAF, which might be quite verbose). +0 on whether to use an atom:people container. I'd way prefer clear and clean inheritance definition to repeating metadata all the way down, even if the metadata uses references to metadata elements defined elsewhere. -- Thomas Broyer
Re: extension elements inside link elements?
Graham wrote: On 24 May 2005, at 5:44 pm, Robert Sayre wrote: FYI: http://www.imc.org/atom-syntax/mail-archive/msg11433.html But if I encounter a link element that's weirdly non-empty and contains markup from some other namespace, that's the kind of situation you're talking about. I think it would be OK to leave behavior undefined as you say. I'm not sure I object to it in principle, though I think it's a weird place for someone to put extentsions, What about the following extension? atom:link href=http://example.com/some/negociated/content; ext:media-typeimage/svg+xml/ext:media-type ext:media-type q=0.5image/png/ext:media-type ext:media-type q=0.2image/jpeg/ext:media-type /atom:link I also think removing that piece of text makes it unclear that the element is normally empty. What about: The atom:link element defines a reference from an entry or feed to a Web resource. Atom doesn't define any child to the atom:link, though it might contain extension markup. -- Thomas Broyer
Re: extension elements inside link elements?
David Powell wrote: Whether the draft allowed it or not, atom:link isn't an extension point. Could you explain why? -- Thomas Broyer
Re: Comments about Extensions (1)
David Powell wrote: Section 6.4: The RNGs in this section require Extension Elements to be in a namespace that isn't the Atom namespace. This requirement is missing from the text. It's actually worse than just that. Section 6.1 defines foreign markup as being markup from other vocabularies. WRT section 6.2 describing extensions to the Atom vocabulary, I understand this definition of foreign markup as markup in a namespace different from the Atom one. Section 6.4 *implies* Extension Elements are foreign markup as the first sentence of that section is Atom allows foreign markup anywhere in an Atom document though it's not explicit at all. Having re-read the draft without looking at the RNC excerpts, the whole section 6 with its subsections are totally unclear about what is foreign markup (or what is behind Atom vocabulary), what are extensions, what are Simple/Structured Extension Elements and how they relate to foreign markup. Even more, I'm wondering why would there be a need to define Simple/Structured Extension Elements in terms of constraints. I suppose that it's a way to distinguish extensions in the form my:extensiontext-only/my:extension from extensions using attributes and/or child elements; and such a distinction is only necessary because we want to provide a hint about how to interpret extensions in the former form (no attribute, text-only content). Wouldn't it be clearer (less obscure) to anyone dropping section 6.4 and just saying something like the following: Elements from foreign markup with no attribute and text-only content MAY be interpreted by an Atom Processor as a property (or name/value pair) of the parent element that encloses it. This specification does not provide an interpretation for other elements. Still about extensions, have I missed something or nowhere the spec allows for extension attributes (I mean namespaced attributes appearing on Atom elements)? I suggest such attributes to be interpreted as a property (or name/value pair) of the element on which it appears. Finally, in section 6.2, in the last sentence, for the purpose of this discussion applies only to the section 6.3 about how to process them: they obviously aren't extensions, are they? I suggest moving this sentence into section 6.3. There might be other things I missed this evening... -- Thomas Broyer
Re: some small comments on 08
A. Pagaltzis wrote: * Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]: * 4.1.3.1 The type attribute Can I circumvent the DIV element by using the media type of XHTML? (I really dislike this combined construct by the way.) I used to find it extremely horrible. Now I’m not sure. There is some symmetry here: with @type=xml, you have to Which @type=xml? Did you mean @type=text/xml? enclose a full XML document, which will always have a root element. The pseudo-XHTML DIV required for @type=xhtml makes XHTML fragments behave the same way. With the difference that this div is not part of the content. I don’t know if I like it. I don’t know if it’s a good solution. But it is consistent on some level, at least. It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in Consensus call on last raft of issues [1] [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Martin Duerst wrote: At 07:34 05/05/22, Thomas Broyer wrote: I'm sorry to raise this issue back again but... The Atom Publishing Protocol defines SOAP bindings. This (in my mind) means there will be WSDL files over there. WSDL rely on XML Schema which in turn are limited to deterministic content models. Will the APP limit Atom entries in SOAP envelopes content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? Are you speaking about potential non-determinism or actual non-determinism? Atom core uses interleaved content models, which are not compatible with XML Schema (or DTD). I call them non-deterministic. I know that RelaxNG as well as other schema languages have been created partly because of this limitation of XML Schema, though I don't think we need interleaving in the case of Atom. If Atom aim to be used on devices/systems with small capabilities, having a clear content model makes the parsing easier, e.g. using a state machine based on SAX. The SOAP-WSDL-XML Schema is another approach of the problem, which is more likely to b a big concern as it is part of Atom (here, the protocol) Is such non-determinism in the core of the Atom format, in potential extensions, or in payloads (e.g. XHTML,...)? Payloads will most likely be parsed as black boxes to retrieve XML document fragments or the raw XML as string. Extensions are a concern but as they're part of core (hey, they are extensions ;o) ) Atom processors might just skip them. -- Thomas Broyer
