Re: PaceEntryMediatype
Just to say that I strongly agree with Jan's points below. We should work to use the link relation type properly, and not get dazzled by the current misuse of the alternate relation. I have been wondering if there would not be a case for different mime types if one wanted to place a number of representations at the same url. One could for example have the following at the same place: - an html version of a blog post - an entry representation of that blog post - a feed for the history of changes to that blog post That would suggest having different media types because one could not place them at the same location if one only has application/atom +xml . That does not decide the issue as to whether it is a good idea to do so. For the moment I find the application/atom+xml;type=entry application/ atom+xml;type=feed more appealing than the other new media types by the way. On the other hand having different mime types for every document format is also crazy. If someone invents a doc to describe cats, and someone else a doc to describe mice, are they going to need a new mime type? And what about a doc to describe policemen, and a doc to describe people? We could end up quickly with an infinite number of mime types which clearly would not help interoperability. Henry On 6 Dec 2006, at 23:22, Jan Algermissen wrote: On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote: It seems pointless for atom:link to have a type attribute at all then. You should be able to decide anything you need to decide by GETting the resource (and sometimes parsing it). Why did we add such a useless feature to the spec? I am pretty sure it wasn't added for being able to tell people: Look, at the other end of this link is a feed. 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? 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? Jan On 6 Dec 2006, at 11:42, Jan Algermissen wrote: On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy [EMAIL PROTECTED] wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. IMHO, there is something going wrong somewhere - and it ain't the media type. I completely agree. On 6 Dec 2006, at 14:26, Jan Algermissen wrote: To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or Ok, HEAD would save the extra payload, butI still think the reason for subscribing is NOT how the representation at the other end looks, it is based on the link semantics.
Re: In San Francisco/Bay Area
Sorry for being so imprecise. I was assuming so too. I don't know why I did not make it clearer. But if there were others who misread this and there are enough of them, we can also do it on Wednesday 13th. Henry On 6 Dec 2006, at 10:14, Terris Linenbach wrote: It is unclear reading this thread whether it's for today which I assume it is. Terris -Original Message- From: Henry Story [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 9:42 PM To: John Panzer Cc: Lisa Dusseault; Atom Protocol; Atom Subject: Re: In San Francisco/Bay Area I'll be there at 6:30pm then. I imagine people will not be wanting to stay very late. Henry On 5 Dec 2006, at 21:26, John Panzer wrote: Lisa ran in to me today and reminded me about the meet up (thanks!). I will try hard to make it; is there a definite time set? (6pm is slightly better for me, but 7pm is okay too.) -John Lisa Dusseault wrote: Thanks for setting this up Henry, I can be there Dec 6. 7pm is much easier to make than 6pm if anybody's coming far, even just from SF. Lisa On Dec 1, 2006, at 12:08 PM, Henry Story wrote: Ok I suggest trying December 6th. Onion or no Onion rings at Tied House. What is dinner time in the bay? 6pm? 7pm? Henry On 28 Nov 2006, at 21:31, John Panzer wrote: Any of those would be good for me. Be careful of the deep fried onion rings at Tied House, though. Henry Story wrote: It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry -- SzHO.gif John Panzer System Architect http://abstractioneer.org
Re: In San Francisco/Bay Area
I'll be there at 6:30pm then. I imagine people will not be wanting to stay very late. Henry On 5 Dec 2006, at 21:26, John Panzer wrote: Lisa ran in to me today and reminded me about the meet up (thanks!). I will try hard to make it; is there a definite time set? (6pm is slightly better for me, but 7pm is okay too.) -John Lisa Dusseault wrote: Thanks for setting this up Henry, I can be there Dec 6. 7pm is much easier to make than 6pm if anybody's coming far, even just from SF. Lisa On Dec 1, 2006, at 12:08 PM, Henry Story wrote: Ok I suggest trying December 6th. Onion or no Onion rings at Tied House. What is dinner time in the bay? 6pm? 7pm? Henry On 28 Nov 2006, at 21:31, John Panzer wrote: Any of those would be good for me. Be careful of the deep fried onion rings at Tied House, though. Henry Story wrote: It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry -- SzHO.gif John Panzer System Architect http://abstractioneer.org
Re: In San Francisco/Bay Area
Ok I suggest trying December 6th. Onion or no Onion rings at Tied House. What is dinner time in the bay? 6pm? 7pm? Henry On 28 Nov 2006, at 21:31, John Panzer wrote: Any of those would be good for me. Be careful of the deep fried onion rings at Tied House, though. Henry Story wrote: It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry
Re: PaceEntryMediatype
There are all kinds of other things you don't know: like what's inside the document, if the server is up, what the title is, ... What interoperability problem is solved by having a new mime type? And would that not be solvable by atom:link rel=entry type=application/atom+xml href=a.xml / Not that I really care that much. Henry On 29 Nov 2006, at 10:22, James M Snell wrote: One such problem occurs in atom:link and atom:content elements. Specifically: atom:link type=application/atom+xml href=a.xml / atom:content type=application/atom+xml src=b.xml / Given no other information I have no way of knowing whether these are references to Feed or Entry documents. - James Mark Baker wrote: -1 - there's nothing special about an entry document - AFAICT (because they're not referenced from the pace), the problems referred to have other causes. I prefer we fix those instead. Mark.
Re: PaceResurrectAutodiscovery
On 24 Nov 2006, at 01:44, Henri Sivonen wrote: On Nov 23, 2006, at 22:42, Henry Story wrote: This is very nice, in that it opens up the possibility of placing good RDF descriptions of these links at the http://www.iana.org/ assignments/relation/, How could new link relations be described in RDF to such a degree that the description would actually be useful for software processing but simple enough to actually be implemented? Is it realistic to have UAs whacking IANA server effectively performing a DDoS on it? Just some interesting uses of this beyond your question: - The RDF file would serve as a useful machine readable description of the relation, and so serve as documentation. - This would simply make those terms re-useable in other rdf vocabularies, which could be very useful. Do you have an RDF file that needs the notion of an alternate link? Well just use elements from that vocabulary. But to get to your point: The description on the server would probably not be very advanced. It would probably be very simple, like the Dublin Core vocabulary ( http://dublincore.org/ ). And so you are right this would probably not say much more than that :alternate is a relation. Perhaps one could even specify the Domain and the Range of the relation to be documents. Not much that one could automate. The default relations would rarely change, so User Agents would never query the server directly, and so you would not have a DDoS on them. On the other hand, clients wanting to define new relations (as URLs) could place the definitions of these relations on their server, and say some more interesting things such as http://my.eg.com/rel#entry rdfs:subPropertyOf http://iana.org/ assignments/relation/alternate . The user agent would now know that this new entry relation is also an alternate relation. Perhaps this could save having to place both relations inside of every document. as well as making the link relation very extensible (people who want to try out new link relations, can just use their own, unambiguous url). How are full URIs distinguished from strings that need to be appended to http://www.iana.org/assignments/relation/; to obtain the full URI? Are UAs supposed to look for a colon as with XForms input methods? Where is this specified? This is specified in the atom syntax document. [[ The value of rel MUST be a string that is non-empty and matches either the isegment-nz-nc or the IRI production in [RFC3987]. Note that use of a relative reference other than a simple name is not allowed. If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string http://www.iana.org/assignments/relation/;. The value of rel describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors. ]] http://www.atompub.org/rfc4287.html#rfc.section.4.2.7.2 In practice people seem to want to use one-word link relations even when they are coming up with their own. Yes. My guess is that this is because 1. They probably don't think of the issue of name clashes 2. There is no shorthand way of saying something like iana:alternate 3. There is no behavior associated with the name If the relation pointed to a document that could have some behavioral impact on the browser with the user could adjust by doing something at the url of the relation, then there would be an immediate understanding of the value of using URIs. I would recommend you adopt that too. Perhaps you can even adopt the iana name space. If we could get them to put the appropriate rdf document at that location, people who created/coined new link relations could describe these relations as being superproperties or subroperties of relations the browser already knows, which would allow the browser to partially interpret those. Well, RDF is not viewed that favorably by the WHATWG. Also, the barrier for entry for the IANA registration process is likely too high. (It certainly is for MIME types.) As for using the same namespace, the HTML5 definitions for the link types don't necessarily match the Atom definitions. I believe I have a good explanation for why people may have good reasons to dislike RDF/XML. see: http://blogs.sun.com/bblfish/entry/crystalizing_rdf Recently, a WHATWG-managed registry for HTML5 rel values has been discussed informally. The idea was that conformance checkers could consult an online registry instead of only allowing a fixed list of values or allowing everything. RDF is an overkill for this. Even XMDP isn't the simplest thing that could possibly work. The simplest thing that could possibly work is a GETtable text/plain; charset=utf-8 resource at a well-known URI with one rel
Re: In San Francisco/Bay Area
It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me
Re: PaceResurrectAutodiscovery
Very nice. One thing I like about the current atom spec, is that the link relations are in fact urls. The link relations are equivalent to the urls generated by appending http://www.iana.org/assignments/ relation/ to the alternate, self, ... rel=... strings. This is very nice, in that it opens up the possibility of placing good RDF descriptions of these links at the http://www.iana.org/ assignments/relation/, as well as making the link relation very extensible (people who want to try out new link relations, can just use their own, unambiguous url). I would recommend you adopt that too. Perhaps you can even adopt the iana name space. If we could get them to put the appropriate rdf document at that location, people who created/coined new link relations could describe these relations as being superproperties or subroperties of relations the browser already knows, which would allow the browser to partially interpret those. Just a thought. Henry On 23 Nov 2006, at 12:05, Henri Sivonen wrote: The latest WA 1.0 draft covers this as follows: If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. http://whatwg.org/specs/web-apps/current-work/#alternate0 The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document; otherwise, the feed is just a syndication feed, not necessarily associated with a particular Web page. http://whatwg.org/specs/web-apps/current-work/#feed0 -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceResurrectAutodiscovery
On 23 Nov 2006, at 14:28, Thomas Broyer wrote: The feed keyword indicates that the referenced document is a syndication feed. Being a syndication feed is expressed by the media type, there's no need for a 'rel' value. The only reason for such a 'rel' is to replace the contents value in the example above: link rel=feed type=text/html href=/index.html / link rel=feed type=application/atom+xml href=/feed.atom / in blog-like use-cases where an HTML page serves the same purpose as a syndication feed, just in an 'alternate' format. Exactly: you have just made one good point why one should not use mime types to identify the relation. After all there may be many different feed representations: html, rss 1.0, rss 2.0, atom, rdf, ... etc... There are many other good reasons to not use the alternate relation everywhere. The spec [1] for feed makes the case for a useful distinction between a feed that can be used to track updates of the content one is looking at, and something that is just an alternate representation of the content one is looking at expressed in application/atom+xml format. This would be the case for the front of my blog page. Henry [1] http://whatwg.org/specs/web-apps/current-work/#feed0
Re: PaceResurrectAutodiscovery
I agree. It would be useful to work on placing a little bit more weight on the rel relation rather than putting everything on the mime type. After all if every link is going to be an alternate relation, then what was the point of the rel=... attribute? We might as well have stuck with simple a href= anchors. I think there is still time to put forward a number of simple relations such as feed, entry or even service or collection. This could be really useful distinctions. Henry On 21 Nov 2006, at 20:46, Eric Scheid wrote: We're in a good position, in this WG, to suggest a future standard. We've delved deeply into the intricacies, we've examined a wide range of use cases. Speaking of which ... there's another use case to consider. Since Atom has promoted interest in using feed documents in an archival manner, it is entirely reasonable to use @rel=alternate to point to an archive feed document which contains the *same* content as the referring page, as opposed to referring to a feed document which has the most recent additions from the same source as where the contents of the current page came from. (what a mouthful!)
In San Francisco/Bay Area
Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me
Re: searches - was Re: Adding POST capability to atom:link
On 8 Nov 2006, at 19:49, Jan Algermissen wrote: On Nov 8, 2006, at 5:57 PM, Henry Story wrote: http://www.intertwingly.net/wiki/pie/PaceSparqlLink Are you really suggesting to use POST for querying (as the Pace says)? Sorry, it was my misreading of SPARQL protocol to think that POST was necessary. You can also use GET, though that would end up creating very large URLs. Not sure if there is a way one could shorten SPARQL queries. Perhaps work for a SPARQL extension. I'll change the Pace. Henry You wouldn't even be able to send someone a link to the [feed that is] the query result or page through the result etc. ?? Jan
searches - was Re: Adding POST capability to atom:link
One very powerful solution would be to use a sparql link as described in PaceSparqlLink [1] This would point to a service end point such as the following: http://roller.blogdns.net:2020/snorql/ to which a simple SPARQL POST or GET request can be made. The above url points to the html view of the form which you can query and find out about all the entries on the attached roller server at http://roller.blogdns.net:8080/roller/ Henry [1] http://www.intertwingly.net/wiki/pie/PaceSparqlLink On 26 Oct 2006, at 18:24, Gopalan Sri wrote: Hello, I am trying to use opensearch to do some paging of my search results and I have a question regard adding POST capabilities to the atom:link construct. The information I want to pass back to the server is complex in nature and makes sense to capture in XML. My question is whether or not there are any thoughts or plans to extend the atom:link contruct to support something like this: 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 Thanks. Sri Gopalan Booz Allen Hamilton Office: Allen 147 Tel: 703.377.1404 Mobile: 703.395.4057
Re: categories and tagging
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] 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. [[ 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, whereas just below [[ The scheme attribute is an IRI that identifies a categorization scheme. Category elements MAY have a scheme attribute. ]] [2] The scheme attribute is defined in terms of an IRI . To give a bit more context to what Andrew was saying, he was arguing that for a mapping between the SKOS [3] vocabulary and the atom vocabulary. SKOS is indeed very interesting. It allows one to say something like http://my.concept.net/my-vocabulary/13745 a skos:Concept; skos:inScheme http://my.scheme.net/my-vocabulary/; skos:prefLabel cats . and much more. The question remains as to how this can be well mapped to atom. If I take one of Tim Bray's examples category scheme='http://www.tbray.org/ongoing/What/' term='Places' / I can translate this to the AtomOwl ontology [4] [] a :Category; :scheme http://www.tbray.org/ongoing/What/; :term Places . Practically, this seems to mean that one can get all the nice info about Places at the url http://www.tbray.org/ongoing/What/Places And this seems to be becoming quite a common way people are setting things up, and also it has some continuity with what the RSS2 folks were doing. [[ category is an optional sub-element of item. It has one optional attribute, domain, a string that identifies a categorization taxonomy. The value of the element is a forward-slash-separated string that identifies a hierarchic location in the indicated taxonomy. Processors may establish conventions for the interpretation of categories. Two examples are provided below: ]] [5] It follows that what we have is something that can be expressed in RDF by saying that the :scheme and the :term relation form a CIFP [8], ie: together they uniquely identify one thing, and furthermore that the identity of the thing is given by the concatenation of those two strings. This seems therefore to capture behavior that is not present in skos, but apart from that the two should be quite complimentary. Let us see how we can make them more so. What we need perhaps is some way to make clear what the url of the category is. We could do this as follows: 1. add a new attribute to identify the category (lets call it catid) 2. Assume that if a catid is not present, and we have scheme and a term attribute, that the catid is formed by the concatenation of the scheme+term we could then write out http://my.concept.net/my-vocabulary/13745 a skos:Concept; skos:inScheme http://my.scheme.net/my-vocabulary/; skos:prefLabel cats . like this category catid=http://my.concept.net/my-vocabulary/13745; scheme=http://my.scheme.net/my-vocabulary/; term='cats' / Now because the term is mandatory in atom (and not the scheme), I suggest that one use the skos:prefLabel for it. I know there is a label too, but well, it certainly makes it easier to search for similar categories using the SPARQL type queries I put forward in [1]. Henry -- Thomas Broyer [1] for the atom-syntax people who may not have been following this thread then, see http://blogs.sun.com/bblfish/entry/ folksonomies_ontologies_atom_and_the [2] http://www.atompub.org/rfc4287.html#element.category [3] http://www.w3.org/TR/swbp-skos-core-guide/ (though I would suggest rewriting the rules using N3, rather than the Jena language) [4] https://sommer.dev.java.net/atom/ [5] http://blogs.law.harvard.edu/tech/ rss#ltcategorygtSubelementOfLtitemgt [6] http://esw.w3.org/topic/CIFP
Re: categories and tagging
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? 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? Since scheme is a URL I can presumably go there to find something. But what? 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 / 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. 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. 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, 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. Henry
html content, xml:base and xml:lang
Does xml:base and xml:lang apply to html encoded content? There is the notion of language sensitivity and content is language sensitive. So it makes sense to apply it to html content. But what about the xml:base? Henry
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 01:40, James M Snell wrote: [snip] The spec says The value of atom:updated is only changed when the change to a member resource is considered significant. The use of passive voice obscures who does what here. When the client doesn't suggest a value for atom:updated, does the server provide one, and if so, how does the server know what is significant? I thought it would always be the client suggesting values, but Tim says that the server controls atom:updated which could imply that the client doesn't even need to suggest values. See above about whether the server MUST accept certain values for updated, or more likely, MUST NOT accept suggested values for updated when they're clearly wrong (e.g. this entry was last updated on October 16, 1906). My assumption: Tim is correct. The server controls atom:updated. While the client is required to provide a valid atom:updated element, the server can (and in most cases will) ignore that value. Completely disagree. If the server controls atom:updated then what was the point of the whole discussion of app:edited? the client controls app:edited. It is the client who decides what if there was a significant change. The server controls app:edited. Any edit, changes app:edited. If you have it your way, then atom:updated will end up meaning app:edited, which Tim Bray specifically mentioned he did not want in his wiki example. Henry
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Many thanks to Lisa for the lengthy and detailed comments. I am just replying to those comments relating to the parts of the spec I understand best. On 18 Oct 2006, at 01:40, James M Snell wrote: *Synchronization* I predict that some AtomPub authoring clients will attempt to synchronize: to maintain an offline copy of the feed including all its MERs and media resources, and to keep that offline copy up-to-date. Some will probably even allow offline authoring of new posts, and offer to synchronize when the client next goes online -- because of the possibility of multiple authors, this may mean at times that the client would download new entries created by other authors, upload new entries created offline, and reconcile its offline copy of feed documents. Because authoring clients will attempt to do this based on Last- Modified and ETag -- after all, the functionality is all there in some form or another -- the spec needs a little more clarity on how the client can rely on this working. Otherwise, some servers may omit features that these authoring clients require, or implement them oddly. While I would never suggest repeating all the requirements from other specs (in this case HTTP), there are cases where clarity and interoperability are greatly improved by at least referencing explicitly requirements from HTTP. It's also possible to add new requirements based on features in HTTP, that apply to Atom servers alone. I would be very happy to see some discussion of this in the spec, especially if it normatively required the use of ETags for offline synchronization. I think synchronisation would be best dealt with by adding functionality to sort the collection in different ways. Currently the sort order is a SHOULD on atom:updated. That does not allow clients to find the most recent edits. If there were a way to sort the entries by app:edited one could find the most recent edits quite quickly. Doing a HEAD on all the entries to find out which changed by comparing etags is not really an option. For large blogs such as Tim Bray's ongoing this would use up way to many resources and take way too long. [snip] of HTTP (calendaring) than the general case. If HTTP synchronization in authoring cases were clearly defined and had not lead to years of arguments since the last HTTP update, I would probably feel differently about just silently relying on the mechanisms in HTTP. +1 In any case, I have very specific brief suggestions to cover synchronization so that it's implemented more successfully than not. - Consider adding a brief section offering clients non-normative guidelines on synchronization. It doesn't have to limit server behavior so much as point out with green and red lights where the fairway is (mixing transportation and golfing metaphors in my head) - Make a few requirements of servers to avoid some of those HTTP ambiguities. For example: The ETag or Last-Modified values for a member resource MUST change when any metadata in the resource changes, as well as text/content, and this includes next and last link relation values. The ETag or Last-Modified values of a member resource MUST NOT change solely because an associated other resource (e.g. the media resource being an associated resource to the media link entry resource) changed. +0.5. I would add that the ETag/Last-Modified values of a resource SHOULD NOT change solely because of non-significant changes to the infoset serialization of an entry (e.g. a different namespace prefix is used, or whitespace is added or removed, etc). I would also prefer that the ETag for a MLE change when it's associated media resource is updated. More open questions that might be related to synch or might have relevance even for clients that don't do full synch: - What is the relationship, if any, between the atom:updated value and the HTTP Last-Modified value. Can the atom:updated value ever be later (greater) than the Last-Modified value? I believe it can be the same or earlier, but the spec doesn't disallow the broken case. My assumption: There is no relationship. atom:updated should be treated as being entirely independent of Last-Modified. yes. It might be reasonable, however, to define a relationship between Last-Modified and app:edited. No. In discussions on the topic of synchronisation it became obvious that people wanted to have servers add properties to entries, such as changing the number of comments for an entry, without this changing app:edited. A new app:modified would be the closest to something that could have a 1-1 relation to Last-Modified. But there was a lot of push back against app:modified as being too britle - ie. changing too often (xml formating changes could cause app:modified to change) - Is it clear whether the client MUST GET the entry after modifying it in order to have an accurate offline cache? (this was
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 16:10, John Panzer wrote: My assumption: Tim is correct. The server controls atom:updated. While the client is required to provide a valid atom:updated element, the server can (and in most cases will) ignore that value. Completely disagree. If the server controls atom:updated then what was the point of the whole discussion of app:edited? the client controls app:edited. It is the client who decides what if there was a significant change. The server controls app:edited. Any edit, changes app:edited. I think you have a typo somewhere in the above. Duh. You are right. I wish there were unit tests for typing docs. Why is it one always has to test everything in life? I meant: If the server controls atom:updated then what was the point of the whole discussion of app:edited? The client controls atom:updated. It is the client who decides what a significant change is. The server controls app:edited. Any edit changes app:edited. Henry
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 16:34, James M Snell wrote: No, it means only that it's the server's responsibility to determine when atom:updated should be updated and when it shouldn't. If the server wishes to delegate that responsibility to the client, then that's fine. Is this not splitting hairs a little? In the end it is always the server who is going to decide if it wants to accept anything at all. The server could also change the content if it wished (though I would not use such a service, having lived through the greed of the .com, we can be assured that servers will want to add their adds to your content). If we use the word responsibility this way then it's not going to help us distinguish anything interesting. When it comes down to it, my feeling was that the client decides whether or not it wants to check that box significant update or not. The client does not have any say in what the value of app:edited is. But special cases can be made. It's just that those would be understood to be deviations from the norm. - James Henry Story meant to write: [snip] If the server controls atom:updated then what was the point of the whole discussion of app:edited? The client controls atom:updated. It is the client who decides what a significant change is. The server controls app:edited. Any edit changes app:edited.
Re: URGENT: Remove atom:updated ordering requirement?
+1 to make the MUST a SHOULD +1 on app:edited But I think it would be really useful if we could have something that allowed the user to specify how the feed should be sorted. Henry On 27 Sep 2006, at 22:14, Tim Bray wrote: co-chair-mode Please see the dialogue below. /co-chair-mode (Eric's point seems plausible to me; personally I'd be inclined to a +1.) co-chair-mode Can we have some feedback from the WG ASAP? We want to take protocol-11 to the IETF. /co-chair-mode -Tim On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote: On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote: PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. There also seems to be universal support for the notion that collection feeds could be sorted by something other than what's currently in the spec. The spec currently not only says collections are to be sorted by atom:updated, but because of the MUST it also says it MUST NOT be sorted by anything *else*, which is a problem. Section 10.0 ¶ 2 says this: The entries in the returned Atom Feed MUST be ordered by their atom:updated property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the atom:updated value of an entry will not affect the position of the entry in a Collection. We need to either strike that entire paragraph, or at the very least make that MUST into a SHOULD. I say +1 to s/MUST/SHOULD/ e.
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
Thanks everyone for this really interesting discussion. I have added a note to this effect to the latest atom-owl ontology [1]. In Atom-Owl we could easily do both. [] :content xhtml:div xml:lang=frOui!/xhtml:div^:xhtml. or we could have [] :content Oui!@fr^:xhtml . or [] :content [ :xhtml oui; :lang en ]. It would be simplest I suppose to have the :xhtml type be defined as always having an div ... element. Except that of course it would look odd for xhtml content that contains an html base tag such as div htmlhead...body.../body/head /div From this discussion it looks like the most reasonable would be to strip the div element. In which case one may wonder what the whole purpose of putting the div in the content really was in the first place. Henry [1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml On 28 Jun 2006, at 23:53, Antone Roundy wrote: On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: The content in the entries below should be handled the same way: entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xhtml:div xml:lang=fr xml:base=http://example.com/ feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xml:lang=fr xml:base=http:// example.com/ feu/ xhtml:div xhtml:a href=axe.htmlaxe/xhtml:a/ xhtml:div /content /entry Of course the end result of both should be identical. Is that what you mean by should be handled the same way? The question is, if the xhtml:div is stripped by the library before handing it off to the app, how is the app going to get the attributes that were on the div? Is the library going to push those values down into the content or act as if they were on the atom:content element (or something similar to that)? BTW, it just occurred to me that pushing them down into the content won't work. Here's an example where that would fail: entry xml:lang=en ... content type=xhtml xhtml:div xml:lang=frOui!/xhtml:div /content /entry Notice that there are no elements inside the xhtml:div for xml:lang to be attached to (and even if there were any, any text appearing outside of them would not have the correct xml:lang attached to it). So it looks like the options (both of a which a single library could support, of course) are: * Strip the div, but provide a way to get the attributes that were on it or * Leave the div
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
On the other hand, if one strips the div element, then :xhtml can no longer be an inverse functional property, as contents with different bases could have very different meanings. Just think of xhtml content with a picture, which in one subtree points to bush, and in another one points to Gore, the relative uri references being the same in both cases. This seems to make it more reasonable to create a new literal type which contains the div. (it makes finding duplicates in an rdf database easier). On that topic are there not xhtml ways to create xml:base and xml:lang elements? Should those not perhaps be used instead on the div element? Henry On 29 Jun 2006, at 00:11, Henry Story wrote: Thanks everyone for this really interesting discussion. I have added a note to this effect to the latest atom-owl ontology [1]. In Atom-Owl we could easily do both. [] :content xhtml:div xml:lang=frOui!/xhtml:div^:xhtml. or we could have [] :content Oui!@fr^:xhtml . or [] :content [ :xhtml oui; :lang en ]. It would be simplest I suppose to have the :xhtml type be defined as always having an div ... element. Except that of course it would look odd for xhtml content that contains an html base tag such as div htmlhead...body.../body/head /div From this discussion it looks like the most reasonable would be to strip the div element. In which case one may wonder what the whole purpose of putting the div in the content really was in the first place. Henry [1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml On 28 Jun 2006, at 23:53, Antone Roundy wrote: On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: The content in the entries below should be handled the same way: entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xhtml:div xml:lang=fr xml:base=http://example.com/ feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div /content /entry entry xml:lang=en xml:base=http://example.com/foo/; ... content type=xhtml xml:lang=fr xml:base=http:// example.com/ feu/ xhtml:div xhtml:a href=axe.htmlaxe/xhtml:a/ xhtml:div /content /entry Of course the end result of both should be identical. Is that what you mean by should be handled the same way? The question is, if the xhtml:div is stripped by the library before handing it off to the app, how is the app going to get the attributes that were on the div? Is the library going to push those values down into the content or act as if they were on the atom:content element (or something similar to that)? BTW, it just occurred to me that pushing them down into the content won't work. Here's an example where that would fail: entry xml:lang=en ... content type=xhtml xhtml:div xml:lang=frOui!/xhtml:div /content /entry Notice that there are no elements inside the xhtml:div for xml:lang to be attached to (and even if there were any, any text appearing outside of them would not have the correct xml:lang attached to it). So it looks like the options (both of a which a single library could support, of course) are: * Strip the div, but provide a way to get the attributes that were on it or * Leave the div
Re: Dublin Core and Atom: Any plans for an (Informational) RFC?
The Atom-OWL group is working on an ontology for Atom. You can find the latest version here https://sommer.dev.java.net/atom/ It comes with a XSLT 2.0 and XQuery 1.0 transform from atom xml to atom-owl. (The XQuery transform is the best). We were thinking of adding relations from the atom-owl vocabulary to the DC vocabulary. Have a look at what is there now, and let us know what you think. Henry On 19 Jun 2006, at 15:31, Andreas Sewe wrote: I wonder whether there are any plans of publishing an (perhaps Informational) RFC on the use of DCMI Metadata Terms in conjunction with Atom feeds and entries? Given both the popularity of that vocabulary in the various flavors of RSS and the fact that it offers numerous useful refinements of Atom's built-in metadata (I still remember the PaceDate* debate), this seems like a good idea to me. So, are there already efforts in this direction? Regards, Andreas Sewe
Atom N3
A new, clearer more concise ontology for atom is now available at https://sommer.dev.java.net/atom/ It comes with an XSLT style sheet to transform atom feeds into turtle, a subset of N3 [1], and is released under a BSD license. Please feel free to contribute bug reports, patches and any other feedback to me or to the mailing list at http://groups.google.com/ group/atom-owl/ Sincerely, Henry Story [1] http://blogs.sun.com/roller/page/bblfish/20060614 Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/
Re: when should two entries have the same id?
On 8 Jun 2006, at 14:44, Elliotte Harold wrote: James M Snell wrote: That's not quite accurate. Two entries with the same atom:id may appear within the same atom:feed only if they have different atom:updated elements. The spec is silent on whether or not two entries existing in *separate documents* may have identical atom:id and atom:updated values. They're ids, not guids. Certainly I would expect that there'll be some accidental conflicts. For instance one site might number its posts post1, post2, post3,...; and a different, unrelated site might do the same. No, they are guids. The datatype for an id is a IRI, which is a generalisaiton of URI. IRIs are constructed in such a way that it should be easy to construct universally unique ones without ever having name clashes. If name clashes there are, this will either be due to incompetence or to malevolence. Henry -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/ cafeaulaitA/
Re: when should two entries have the same id?
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... Henry On 7 Jun 2006, at 19:29, Robert Yates wrote: This relates to work that we are doing with the publishing protocol, but is syntax related. In an implementation of APP a single entry can appear both in the APP collection and in any number of arbitrary feeds that the site subsequently offers. These feeds / collections can be optimized differently depending on the client. For example, an entry in the collection feed may have its content out of lined whereas the same entry rendered in a feed may have its content inlined. There are other different optimizations that we are investigating, that cause the entry representation in various feeds / collections to be different, even though it has originated from the same source. So are these representations in the different feeds / collections the same entry or different entries? Should they have the same id? and if a feedreader comes across two entries with the same atom id, what, if anything, can it infer from that? is it only that they came from the same source? Many Thanks, Rob
Re: when should two entries have the same id?
Yes, I know, the atom syntax doc does not make statements about what happens in different feeds. But that does not mean that we are not forced logically to a conclusion. There was a very in depth discussion of this by the way on the atom semantics [1] mail list this February. I think the Atom Protocol is forcing the issue towards there being only one entry per update time stamp. When you publish an entry with an updated time stamp it is going to have to appear in a feed at some point. And that won't be possible unless you overwrite one or the other entries. Also think of agregators. If you have the same entry with the same id but different content, which is it going to choose? Henry [1] http://groups.google.com/group/atom-owl/browse_frm/thread/ 357e36c4ee9cd31b/ On 7 Jun 2006, at 20:40, James M Snell wrote: Henry Story wrote: You can have two entries or feeds with the same id, as long as they have different updated time stamps. That's not quite accurate. Two entries with the same atom:id may appear within the same atom:feed only if they have different atom:updated elements. The spec is silent on whether or not two entries existing in *separate documents* may have identical atom:id and atom:updated values. Consider the case where my personal weblog publishes two Atom feeds. One is a full-content feed that publishes content as XHTML. The second is a partial-content feed that strips the markup and publishes content as plain text in the atom:summary while containing an atom:content with a src attribute to the original XHTML. They exist in two separate Atom documents and both are based on the same underlying blog post. The atom:id and atom:updated values for each entry are identical. Another example. I post an iCal file to an APP collection. In the collection feed, I see a media link entry that uses content/@src to point to the iCal. However, another feed that is used to provide a summary of upcoming events has entries whose content element contains an XHTML rendering of the iCal files. Each entry in the summary feed corresponds to exactly one entry in the APP collection; should they or should they not use the same atom:id and atom:updated values? - James 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... Henry On 7 Jun 2006, at 19:29, Robert Yates wrote: This relates to work that we are doing with the publishing protocol, but is syntax related. In an implementation of APP a single entry can appear both in the APP collection and in any number of arbitrary feeds that the site subsequently offers. These feeds / collections can be optimized differently depending on the client. For example, an entry in the collection feed may have its content out of lined whereas the same entry rendered in a feed may have its content inlined. There are other different optimizations that we are investigating, that cause the entry representation in various feeds / collections to be different, even though it has originated from the same source. So are these representations in the different feeds / collections the same entry or different entries? Should they have the same id? and if a feedreader comes across two entries with the same atom id, what, if anything, can it infer from that? is it only that they came from the same source? Many Thanks, Rob
formal methods: AtomOwl
A week ago I attended the W3C Technical Plenary Week in Cannes (France). There was an very interesting session on Formal Methods at the W3C [1]. The specs that had benefited from working with formal methods were: - XQuery - OWL and RDf - Web Services Choreography and Web Services Descriptions (using pi notation) - WSDL 2.0 (using Z notation) In some cases parts of the formalization became the authoritative work, in others they only had a guiding and clarifying role, and the english text remained the authoritative work. But in every case the feeling was that the formal backing helped work out a lot of problems that were difficult to notice in the natural language text. Now each of the formal methods languages used is in the end back by Set Theory, which RDF and OWL and other semantic web enterprises are based on. My suggestion was therefore that RDF/OWL could itself be a formal language one can use to help explicate various standards. The work being done by the AtomOwl group could then be understood to simply be a formalization of the work done by the atom syntax and APP groups, where the spec release by these groups remain the authoritative texts. The advantage of the Semantic Web languages over these other formalisms is that it is much more widely understood, is web centric, and furthermore has some very interesting direct practical applications. AtomOwl [2] could for example be directly used to help create Sparql end points for aggregators [3], as well as being used directly as a data model as BlogEd does [4]. It is in this light that I am looking to set W3C Working Group (or XG) to create a standard ontology for Atom. As a formalization of Atom it will have to be faithful to the specs released by these IETF groups, which as stated, remain authoritative. There is interest from IBM, Talis Information and Sun Microsystems, three members of the W3C to work on this. If other members would like to join we would be more than happy. We would be very interested to hear from other members of the Atom group on how we can proceed to make the resulting spec be of the highest possible quality. Ideally we would like to place the resulting document at the Atom namespace location with some (XSLT?) transform that would be the default transform from atom to RDF. We are very open on what the best way to proceed is. Yours sincerely, Henry Story Sem Web Researcher, Sun Microsystems http://blogs.sun.com/bblfish/ [1] Session 7: Adventures in Formal Methods http://www.w3.org/2006/03/01-TechPlenAgenda.html [2] http://bblfish.net/work/atom-owl/2005-10-23/ [3] see http://www.intertwingly.net/wiki/pie/PaceSparqlLink [4] https://bloged.dev.java.net/
further refinements to the APP model of Collections
My first N3 representation of the example Service document, with 3 classes :Service, :Workspace, and :Collection a :Service; :workspace [ a :Workspace; :title Main Site@en; :primaryCollection [ a :Collection; :title entries@en; :href http://example.org/myblog/entries; :member-type :entry ]; :primaryCollection [ a :Collection; :title photos@en; :href http://example.org/myblog/fotes :member-type :media ] ]; :workspace [ a :Workspace; :title Side Bar Blog@en; :primaryCollection [ a :Collection; :title Remaindered Links@en; :href http://example.org/ reilly/list; :member-type :entry ] ] . We can think of a Collection as a Feed. Perhaps a subclass of feeds document resources at which one can also post? Perhaps we can even specify this by creating two classes :EntryCollection and :MediaCollection which we can define as follows :Collection rdfs:subClassOf atom:Feed; rdfs:label Atom Application Collection; rdfs:comment An resource to which one can POST resources, and which presents itself as an atom feed; owl:unionOf ( :EntryCollection :MediaCollection ). :EntryCollection rdfs:subClassOf :Collection; rdfs:label Entry Collection class; rdfs:comment One should only POST atom entries to entry collections . :MediaCollection rdfs:subClassOf :Collection; rdfs:label Media Collection class; rdfs:comment Content posted to this collection will create an entry and be the content of the created entry; owl:disjointWith :EntryCollection . Let us keep it simple and ignore the primary and secondary collection distinction. Our example above could then be better written as a :Service; :workspace [ a :Workspace; :title Main Site@en; :collection [ = http://example.org/myblog/entries; a :EntryCollection; :title entries@en ]; :collection [ = http://example.org/myblog/fotes; a :MediaCollection; :title photos@en ] ]; :workspace [ a :Workspace; :title Side Bar Blog@en; :collection [ = http://example.org/reilly/list; a :EntryCollection; :title Remaindered Links@en; ] ] . Because collections are subclasses of Feeds, we can also add the other feed properties, such as id, author, updated, etc, to them if we want. Of course no need to add entries in the Service document itself as that would be of no interest. If we represent things as above then we would have to specify that the title be the title of the feed at the href location. But that does not seem very controversial. Why not nail that down in the spec? Henry
Re: Feed paging and atom:feed/atom:id
I think they should all have the same id. But I don't have any good arguments in favor. It just seems to make sense that way. Henry On 10 Mar 2006, at 18:44, James M Snell wrote: If the feeds have the same atom:id, I would submit that they form a single logical feed. Meaning that all of the feed documents in an incremental feed (using Mark's Feed History terminology) SHOULD use the same atom:id value. This is the way I have implemented paging in our APP implementation. If the linked feeds have different atom:id values, they should represent different logical feeds. Thoughts? - James
wiki mime type
Silly question probably, but is there a wiki mime type? I was thinking of text/wiki or text/x-wiki or something. I want people to be able to edit their blogs in wiki format in BlogEd and be able to distinguish when they do that from when they enter plain text, html or xhtml. Perhaps this is also useful for the protocol. Henry
Re: todo: add language encoding information
On 1 Feb 2006, at 02:10, Eric Scheid wrote: On 31/1/06 1:27 PM, James Holderness [EMAIL PROTECTED] wrote: Actually I was thinking just a regular href and type. For example: link type=application/atom+xml href=http://mydomain.com/feed; hreflang=fr x:id=french_entry_id x:updated=2005-11-15T18:30:02X / I'm not sure how valid that is considering a client that didn't understand this extension would consider the full feed to be an alternative for that one particular entry which doesn't seem right. Any reason that application/atom+xml document couldn't be an Atom Entry Document, apart from the current lack of reader/browser support? It could also then include the links necessary to subscribe to the specific language feed. I think that was one of James' original suggestions. It seems like one good solution. The only problem is that it forces people to have Entry Documents. I am just writing up a document listing all the different ways one can solve this problem... e.
Re: todo: add language encoding information
). [[ There needs to be a debate as to whether multilingual representations of an entry can exist simultaneously. Ie. is this a special case where SHOULD rule can be broken? ]] 1. give entries urls When entries have urls then it is easy to link to them. Here is an example: feed ... entry link rel=self type=application/atom+xml href=entries/en/ e1.atom/ titleAtom-Powered Robots Run Amok/title link type=application/atom+xml hreflang=fr href=entries/fr/e1.atom/ idtag:eg.com,2005/en/atom03/id updated2003-12-13T18:30:02Z/updated summarySome text./summary ... /entry entry link rel=self type=documents/atom+xml href=entries/fr/e1.atom/ titleRobots Atomiques se révoltent/title link href=http://example.org/2003/12/13/atom03/ link type=application/atom+xml hreflang=en href=entries/en/e1.atom/ idtag:eg.com,2005/fr/atom03/id updated2003-12-13T18:30:02Z/updated summarySome text./summary ... /entry /feed The disadvantage is that one has to place entries at well known locations for this to work correctly, which creates duplication of entries (one in the feed, and one on the hard drive). The protocol may force this issue anyway. (does the atom protocol force entries to have urls, so they can be GET, PUT, and DELETEed?) 2. if entries do not have URLs -- Then one can only point to entries by their id. But since ids are not dereferenceable, this is not very helpful. It would tell the reader of the entry that this is an entry whose metadata has an alternate language version, and so it would/could reduce the number of alterts a client would need to send out (he has already seen the alternate entry for example). this would require a new link type link rel=translate hreflang=en href=tag:eg.com,2005/en/atom03 where the href points to the id of the translated entry. I suppose one would assume that at the time of the entry update the relations was true. Now if one wanted to find the feed in which the entry with that id had appeared one would have to add an extension to the link such as xxx:feedhref=http://example.org/feed.atom; link rel=translate hreflang=en href=tag:eg.com,2005/en/atom03 xxx:feedhref=http://example.org/feed.atom; where xxx:feedhref would point to a feed document that forms part of a next, prev chain of such documents that constitute a feed, in which the other language version entry could be found (among other places) QUICK CONCLUSION The simplest and least powerful solution of simply having entries with the same id but in different languages is (very probably) not possible because of the SHOULD restriction in the spec. This makes it impossible for one to just state that feeds are translations of each other, as it would not help one work out which entries in one feed were translations of which entries in the other feed. We need a link relation to relate entries. The link alternate pointing to an entry would work best if entries had urls that were dereferenceable. Otherwise one needs to create new translation link relation that points to an entry id in its href. This would not be very helpful in finding the translated entry (unless of course the id of an entry was the same place as that at which it could be GET, PUT, POST and DELETEd) Henry Story PS. Not sure what I should do with the above. Perhaps write it up somehow? On 31 Jan 2006, at 02:17, James Holderness wrote: Henry Story wrote: Just re-reading your mail I think you make a good point that perhaps translation is the wrong word to use. We would like something more abstract such as otherLanguageVersion. This made me think that the word we want is alternate. And then looking at the spec again I found the following: [[ 4.2.7.4. The hreflang Attribute This was the first thing I suggested... If you want to link the various translations together you can add one or more link elements at the top of the feed with rel=alternate and hreflang set to the language of the alternate feed. If you're feeling really enthusiastic you can include alternate links pointing to the translated html pages for each entry too. [1] Regards James [1] http://www.imc.org/atom-syntax/mail-archive/msg17609.html
Re: todo: add language encoding information
On 31 Jan 2006, at 03:27, James Holderness wrote: Personally I would have preferred using a fragment identifier. So the above example would look something like this: link type=application/atom+xml href=http://mydomain.com/feed#french_entry_id; hreflang=fr x:updated=2005-11-15T18:30:02X / And a link to an entry within the same feed could be done with a fragment only uri, like this: link type=application/atom+xml href=#french_entry_id hreflang=fr x:updated=2005-11-15T18:30:02X / But from what I can make out, this sort of thing would only be valid if atom:id was defined to be an ID attribute which would assumedly require an Atom DTD. And that won't be quite possible because: - a feed can have a number of entries with the same id, whereas I think that when something is defined as being an ID attribute there can only be one instance in the same document (not absolutely sure about this though) - an id is not an attribute in atom xml, so I am not even sure this would be possible anyway Also it is quite possible that the entry fall off the end of the feed after a while (usually just before it gets placed into an archive). So the link in your first example above would be falsified a little too easily. Henry Story http://bblfish.net/
Re: todo: add language encoding information
This looks like a good place to look for a solution. On 31 Jan 2006, at 03:27, James Holderness wrote: Henry Story wrote: Presumably one would need to add an x:feed=http://mydomain.com/ feed attribute for translations of entries that appear in other feeds. Actually I was thinking just a regular href and type. For example: link type=application/atom+xml href=http://mydomain.com/feed; hreflang=fr x:id=french_entry_id x:updated=2005-11-15T18:30:02X / I'm not sure how valid that is considering a client that didn't understand this extension would consider the full feed to be an alternative for that one particular entry which doesn't seem right. Your point is well taken that the extension would be confusing for tools that did not understand it. Perhaps one could create a new link rel=translation that would point to a feed containing an alternate entry with the given x:id and updated at the particular time. link rel=translation type=application/atom+xml href=http://mydomain.com/feed; hreflang=fr x:id=french_entry_id x:updated=2005-11-15T18:30:02X / would that still be confusing to tools that did not understand the extension? Henry
Re: Atom2RDF via Universal Feed Parser
On 29 Jan 2006, at 16:47, Danny Ayers wrote: fyi, Chimezie has a blog post [1] including the mapping below between Atom as interpreted by Mark Pilgrim's UFP (so it'll also work for anyRSS) to RDF. [snip] I don't quite understand what is going on in that blog post. At some point it'll probably be a good idea to capture the mapping from the core Atom constructs (as expressed in Atom/OWL [2]) to the other vocabs/ontologies used - FOAF, SKOS, DC, presumably through owl:equivalentClass/owl:equivalentProperty statements. (APP construct mappings to follow, when someone's got a bit of time...) atom-owl already uses the foaf ontology for foaf:Person construct. for DC there was some mapping someone made between DC and atom- constructs. There was this wiki page: http://www.intertwingly.net/wiki/pie/PaceEquivalents My guess is that I could add some inheritance properties to atom-owl. Something like: awol:id rdfs:subclassOf dc:identifier . we would have to look at this case by case. Also should this be part of the main ontology? Henry Story
Re: todo: add language encoding information
Sorry for being away for a while. I am back on this issue. We had narrowed in on this quite well. It should be RFC time real soon. On 24 Dec 2005, at 07:25, James Holderness wrote: Henry Story wrote: I think you have not quite grasped the point my graph was trying to make. Perhaps I did not explain myself clearly enough. The graph represents a feed with three entries A, B and C. B and C share the same id. C has an updated time stamp that is after B so C is an update of B. If you went with my link+hreflang method, this could be handled with an additional date attribute in the link, where the date signified the time at which the translation was valid. For example: Yes. Quite right. entry idtag:eg.com,2005:/en/atom03/id link hreflang=fr x:id=tag:eg.com,2005:/fr/atom03 x:updated=2005-11-15T18:30:02Z/ /entry entry idtag:eg.com,2005:/fr/atom03/id updated2005-11-13T18:30:02Z/updated link / /entry entry idtag:eg.com,2005:/fr/atom03/id updated2005-11-15T18:30:02Z/updated link / /entry Presumably one would need to add an x:feed=http://mydomain.com/feed; attribute for translations of entries that appear in other feeds. I've left off the obvious elements and attributes for brevity, but you get the idea. yes I do. Henry
Re: todo: add language encoding information
Sorry again to take so long to respond. I have been a little too busy to respond recently. On 4 Dec 2005, at 16:42, Simon Phipps wrote: On Dec 4, 2005, at 14:33, Henry Story wrote: I have written my first blog entry in French [1] which has made me aware that it would be very useful to add language information to the atom file generated by BlogEd. A menu beneath the Entry icon would probably do the trick. Henry [1] http://bblfish.net/blog/page9.html#t2005_12_04.14_17_02_642 Does Atom allow there to be multiple parallel renditions of a blog entry in different languages? I've been discussing with Dave Johnson how we might provide a facility in Roller where a blog entry might be provided in multiple languages and then select the appropriate entry based on the contents of the HTTP GET. If this were to be implemented, we'd need a way to express the same reality in the Atom feed. This is a complicated and delicate issue. An atom entry has been syntactically limited by the atom spec by the following clause [[ If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, they represent the same entry. Their atom:updated timestamps SHOULD be different. If an Atom Feed Document contains multiple entries with the same atom:id, Atom Processors MAY choose to display all of them or some subset of them. One typical behavior would be to display only the entry with the latest atom:updated timestamp. ]] last para of section 4.1.1 of http://www.ietf.org/rfc/rfc4287 So it is not really possible to put atom entries with the same id and updated time stamp in a feed (without a SHOULD level violation) even if they are translation of each other. That means that the Swiss would not be able to publish a law with the same atom id in french and in german, as they are obliged to publish these at the exact same time by law. (No linguistic preference) If we want to respect this we have to give different translations of a document different ids. We should be able to specify that they are translations of each other some other way. Using the Atom OWL ontology [1] we could do this by adding some translation relation between the entries. Once this the best way to do this is settled and that it satisfies our needs it should be possible to put a proposal to the atom syntax group for an extension to their xml format. So perhaps something like this is needed [ a :Feed, :Version; :title [ :value Example Feed; :type text/plain ]; :link [ :href http://example.org/; :rel iana:alternate ]; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :author [ :name John Doe ]; :id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6; :entry [ a :Entry; :title [ :value Atom-Powered Robots Run Amok; :type text/plain ]; :link [ :href http://example.org/2003/12/13/en/atom03; :rel iana:alternate ]; :id tag:example.com,2005/en/atom03; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value After a course of integration in French philosophy,...; :type text/plain ]; ext:translation tag:example.com,2005/fr/atom03 ]; :entry [ a :Entry; :title [ :value Des Robot Atomiques se rebellent; :type text/plain ]; :link [ :href http://example.org/2003/12/13/fr/atom03; :rel iana:alternate ]; :id tag:example.com,2005/fr/atom03; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value Apres un cours d'integration en philosophie francaise...; :type text/plain ] ext:translation tag:example.com,2005/en/atom03 ]; ] . The ext:translation relation above relates a :Entry to an :EntryId which is to say that it cannot distinguish between one version of an entry and another. So we would either be saying that each version of one entry is always going to be a translation of the other, or that there is some version of the other entry that is a translation of this one (which is a little too vague for comfort). We could be more precise by giving each entry version its unique id, in which case we could say that this particular entry is a translation of that particular entry, which would be more precise and satisfactory. In N3: [ a :Feed, :Version; :title [ :value Example Feed; :type text/plain ]; :link [ :href http://example.org/; :rel iana:alternate ]; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :author [ :name John Doe ]; :id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6; :entry [ a :Entry; = _:someid1; :title [ :value Atom-Powered Robots Run Amok; :type text/plain
Re: todo: add language encoding information
Simon is not a member of the atom-syntax list. I imagine his response will get through atom syntax moderation at some point, though as we are in holiday season, I imagine this could take some time. I have also changed the policy on [EMAIL PROTECTED] to allow posts by non members, forcing them through a moderation stage. This option was not available on google groups when I started the group. So you non members can cc that group hapily now. :-) Henry On 22 Dec 2005, at 18:44, Simon Phipps wrote: On Dec 22, 2005, at 15:34, James Holderness wrote: Henry Story wrote: Does Atom allow there to be multiple parallel renditions of a blog entry in different languages? So it is not really possible to put atom entries with the same id and updated time stamp in a feed (without a SHOULD level violation) even if they are translation of each other. That means that the Swiss would not be able to publish a law with the same atom id in french and in german, as they are obliged to publish these at the exact same time by law. (No linguistic preference) The Swiss may need to publish laws in multiple languages simultaneously, but most users surely don't need to read those laws in multiple languages simultaneously. Why waste their bandwidth including several translations in one feed when it would be far more convenient if you just had a separate feed for each language? You're making a couple of dodgy assumptions here: * You're assuming Atom is just used by an end-user here. Atom feeds can also be used to pass data between servers, for backup, or for content transfer. Structuring multilingual data as multiple feeds without including cross-relationships with the data involves loss of meta-data. * You're assuming multiple languages are always present. When I blog, I have some entries translated for me because they relate to local issues in a country I am visiting. I won't be making a permanent pt-br feed when I visit Brazil, but I may well want the translated blog entry to be made available in the syndication feed. It may well be appropriate to have multiple feeds in the case Henry cites where there is a stable set of translations, but the more general case merits serious consideration. James Snell has an interesting proposal that addresses the issue directly with minimal change. S.
Re: todo: add language encoding information
Simon makes some good practical points in the message I forwarded just previous to this one. But I would like to make some more abstract points too for those of you who are more of the Jungian introspective/rational character types (most of us here I guess or else we would be out surfing on the beach ;-) On 22 Dec 2005, at 16:34, James Holderness wrote: Henry Story wrote: Does Atom allow there to be multiple parallel renditions of a blog entry in different languages? So it is not really possible to put atom entries with the same id and updated time stamp in a feed (without a SHOULD level violation) even if they are translation of each other. That means that the Swiss would not be able to publish a law with the same atom id in french and in german, as they are obliged to publish these at the exact same time by law. (No linguistic preference) The Swiss may need to publish laws in multiple languages simultaneously, but most users surely don't need to read those laws in multiple languages simultaneously. Why waste their bandwidth including several translations in one feed when it would be far more convenient if you just had a separate feed for each language? The atom syntax has a very clear restriction which I believe is of semantic importance [1]. And that is as I mentioned in my original post that: [[ If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, they represent the same entry. Their atom:updated timestamps SHOULD be different. If an Atom Feed Document contains multiple entries with the same atom:id, Atom Processors MAY choose to display all of them or some subset of them. One typical behavior would be to display only the entry with the latest atom:updated timestamp. ]] last para of section 4.1.1 of http://www.ietf.org/rfc/rfc4287 What would be the point of having this restriction if it was not of semantic significance? It seems a little odd to tell people that they cannot put two entries into a feed with the same updated time stamp, but that they can put them into two different feeds and all is ok. Why have that restricition in that case? My guess is that the restriction was accepted because it worked on the following intuition. The atom id is a string that identifies something we can think of as a document. It therefore does not make sense to have two different incompatible versions of the same document with the same time stamp. The atom id is therefore much more restrictive than a URL [2]. A URL in web architecture can have any number of different representations at the same time. Atom clearly rules this out. So my guess is that we should take this seriously. The id is identifying a document. And a document cannot be wholly in two languages at once. Once we accept this, then there is no big problem. We just need the translations to have 2 different ids. They are after all two different documents. We can then put the two translations into the same feed, or different feeds without problem. All we need is to find a way to state that one document is a translation of the other. And James Snell's proposal is a good start at getting us there (it is a possible translation of the N3 proposal in my original e-mail). If you want to link the various translations together you can add one or more link elements at the top of the feed with rel=alternate and hreflang set to the language of the alternate feed. If you're feeling really enthusiastic you can include alternate links pointing to the translated html pages for each entry too. If my argument above is sound then we should be able to put the translations in the same feed. What we want to do then, is find some way to state that one entry in the feed is a translation of the other entry in the same feed. So though the solution saying that one feed is a translation of the other is ok (apart from it breaking what I think are the inherent semantics in atom) it is also too general. We need more precise tools. No extensions need to be made to the Atom spec. No wasted bandwidth by having multiple translations in a feed that may not be used. But you can still publish muliple language simultaneously by making sure you update all feeds simultaneously. You could even publish all the feeds at the same URL, serving the correct translation based on the HTTP Accept-Language header. Those are cool ideas. But again, it would be good to have a way to specify that an entry in one feed is a translation of a particular different entry in the other feed. I may be missing something here, but it seems to me like a reasonable solution to the problem. Those were my first thoughts too btw. And also Retos. :-) Regards James I hope this type of argument also helps show how the semantics we are working on at the atom-owl group can help reveal hidden meanings lurking
Re: todo: add language encoding information
I still think it would be good to be able to have to entries in one feed and be able to state that they are translations of one another. I don't think that putting them in different feeds is going to cover all the cases. See below. On 22 Dec 2005, at 17:45, James M Snell wrote: One possibility for this in Atom is to provide multiple Atom documents, each covering their own language. Given that the date restriction only covers Atom entries within the *same* feed document, the following would be perfectly acceptable: feed xml:lang=de ... entry idtag:example.org,2005:some_entry/id ... /entry /feed feed xml:lang=fr ... entry idtag:example.org,2005:some_entry/id ... /entry /feed [note I change my mind on this half way through the thought] Ah. I did not read your post carefully enough when posting my previous reply to James Holderness. I don't in fact think this is ok. If the date restriction covers entries inside the same feed (which can be millions of entries long btw) it has to do so for some good reason. Or else why put the restriction in there at all? Now that atom is final, and we cannot change the restriction I think we had better assume it is there for a very good reason. That will make us all look more intelligent that otherwise for one. So my best explanation is that the id at a time identifies one and only one entry - universally, semantically if you will. If books had isbn numbers that persisted over editorial changes then this would be equivalent to our id. By using the isbn number of a book we could then refer to all the transformations of that book. But it would not make sense perhaps to have two different books versions published at the same time, with the same isbn number... (no that makes sense?!)... by the same publisher... Oops. That looks like the feed has taken the role of the publisher in the analogy... (ponders) Ok. So that would make me change my mind. It should be possible to have two entries with the same id and the same updated time stamp but different content in two different feeds. This would suggest that the feed is really part of the identity of the entry (and that the motto it's the entry stupid is wrong). To indicate that the feeds were translations of one another, a new translation link rel could be established on the feed level feed xml:lang=de ... link rel=translation hreflang=fr href=http://.../thefeed?lang=fr; entry idtag:example.org,2005:some_entry/id ... /entry /feed feed xml:lang=fr ... link rel=translation hreflang=de href=http://.../thefeed?lang=de; entry idtag:example.org,2005:some_entry/id ... /entry /feed I still would suggest it be better to have different ids for the translations so that they can be put in the same feed. After all, why not allow that? If I am a publisher and I am publishing books, why could I not simultaneously publish a book and its translation? It should be possible then somehow to state that one entry is a translation of the other. Is there a way to do what I was going trying to state here in N3. This is really the problem that Simon Phipps was looking at. [ a :Feed, :Version; :title [ :value Example Feed; :type text/plain ]; :link [ :href http://example.org/; :rel iana:alternate ]; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :author [ :name John Doe ]; :id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6; :entry [ a :Entry; = _:someid1; :title [ :value Atom-Powered Robots Run Amok; :type text/plain ]; :link [ :href http://example.org/2003/12/13/en/ atom03; :rel iana:alternate ]; :id tag:example.com,2005/en/atom03; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value After a course of integration in French philosophy,...; :type text/plain ]; ext:translation _:someid2; ]; :entry [ a :Entry; = _:someid2; :title [ :value Des Robot Atomiques se rebellent; :type text/plain ]; :link [ :href http://example.org/2003/12/13/fr/ atom03; :rel iana:alternate ]; :id tag:example.com,2005/fr/atom03; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value Apres un cours d'integration en philosophie francaise...; :type text/plain ] ext:translation _:someid1; ]; ] .
Re: [Fwd: Re: todo: add language encoding information]
Yes. That is one solution. But what we are looking for is how one can state that two entries in the same feed are translations of one another. Henry On 22 Dec 2005, at 20:52, James M Snell wrote: Hmmm.. interesting thought, hadn't considered that. rel=self should always point to *this* document, and never to some other document, but if the document referenced is the same document just in a different language, then it is possible? Good thinking but I'm not sure if it's legal according to the spec. feed xml:lang=de ... link rel=self hreflang=fr href=http://.../thefeed?lang=fr; link rel=self hreflang=de href=http://.../thefeed?lang=de; entry idtag:example.org,2005:some_entry/id ... /entry /feed - James A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2005-12-22 19:30]: To indicate that the feeds were translations of one another, a new translation link rel could be established on the feed level feed xml:lang=de ... link rel=translation hreflang=fr href=http://.../thefeed?lang=fr; entry idtag:example.org,2005:some_entry/id ... /entry /feed feed xml:lang=fr ... link rel=translation hreflang=de href=http://.../thefeed?lang=de; entry idtag:example.org,2005:some_entry/id ... /entry /feed Is that even necessary? Wouldn’t @rel='self' already work here? Regards,
Re: Atom, files and directories: what it's all about
On 1 Dec 2005, at 17:50, Uche Ogbuji wrote: On Tue, 2005-11-29 at 10:25 +0100, Henry Story wrote: On 29 Nov 2005, at 00:31, Luke Arno wrote: On 11/28/05, Ernest Prabhakar [EMAIL PROTECTED] wrote: Hi Henry, On Nov 23, 2005, at 3:22 AM, Henry Story wrote: A few improvements of atom over directories is that our feed can contain not just the current version of an entry, but all previous versions as well, which I think I remember was a feature supported by the vms file system. Interesting. It reminds me of a thought I had a while ago: would it be possible to emulate 80% of WebDAV by using HTTP + Atom? I think that is very much the idea. If you check what is going on on the atom protocol group you will find that they are moving in that direction http://bitworking.org/projects/atom/ Hmm. I worry about such a land grab. I'd rather put muscle behind WebDAV and be sure that Atom dovetails. I think that the similarities should be used to ensure such dovetailing, rather than to seed a competition between Atom and DAV. I don't think this need be thought of as a landgrab. For one it is probably a consequence of atom trying to do the simplest thing possible. When you think about it, a file system or directory hierarchy is probably one of the simplest things around. It is not surprising that if you think about content and publishing content you end up with something that is very very similar to what we had before. Secondly Atom is already finished. It can hardly be claimed that atom (and all the RSS formats before it) tried to grab hold of something unintentionally. 'Grabbing' involves a conscious act, an intention. If you think of Atom as a mathematical structure which in some sense it is (if you follow some of the work of the atom-owl group) then you are closer to understanding the type of grabbing that is happening here. It is just simply that there is a strong isomorphism between these two structures [1]. You and me are very similar. We are both human. And there is an isomorphism there too. But I never intended to grab you :-) Mentioning WebDav further reinforces the parallel with file systems now that I think of it. If you look at the parallel between atom and WebDav, and compare this with the parallel between a plain unix file system and a metadata enabled one, we have a very illuminating parallel. A plain file system is the simplest thing around pretty much and as a result it is the most wide spread type of file system. Atom and RSS follow a similar pattern. They are much more widely available than WebDav implementations. WebDav on the other hand is really very similar to the metadata enabled file systems such as the one shipped with Apple's Tiger [2]. In WebDav you ask the file directly for its properties using PROPGET; in Tiger you do that using tools such as xattr. % xattr --set name John file % xattr --set color red file % xattr --list file file color red name John So with this paralell in mind Simple File System / Atom Metadata File System / WebDav it becomes possible to further see how there is no landgrab happening at all. Notice that both normal file systems and metadata file systems can coexist quite peacefully. In fact OSX allows you to copy a file with metadata to a non metadata enabled file system without trouble and without loosing your metadata. Furthermore I imagine it would be quite possible to publish atom files to WEBDAV systems. Certainly it would be interesting to look into these parallels further. Henry Story [1] http://en.wikipedia.org/wiki/Isomorphism [2] http://arstechnica.com/reviews/os/macosx-10.4.ars/7
Re: Atom, files and directories: what it's all about
Thanks Uche for making me think a little more carefully about this topic. Your intervention has been very helpful in identifying a concern that is probably more widespread than openly acknowledged. On 1 Dec 2005, at 21:20, Uche Ogbuji wrote: Hmm. I worry about such a land grab. I'd rather put muscle behind WebDAV and be sure that Atom dovetails. I think that the similarities should be used to ensure such dovetailing, rather than to seed a competition between Atom and DAV. I don't think this need be thought of as a landgrab. It needn't be, of course, but I think your characterization so far gave the impression that it could be. Nevertheless, I think I'll leave off this thread. After all, it's all vapor so far, and so no real problem. If people do start coming up with WebDAV-replacement ideas, and seriously advocating them, I can take up the cause then. Until then, it's all academic. Seeing something as something else is a very important aspect of learning. This reminds me of various mathematical puzzles one learns in school. It is a long time since I studied geometry but I can remember the importance of seeing a shape as the sum of two others. Was it by these means that the Greeks prooved the irrationality of the square root of 2? [1] I can't remember. But there are many other examples along these lines, I am sure. These questions may be academic, but one should not disparage academia. It is from those quarters that some of the greatest changes in the human condition of stemmed from. I will say while ducking through the door (sorry) that I don't think the distinction between simple file system and metadata file system is all that instructive, but again I'll have to take up that matter if it comes up again in a more practical context. If the only practical effect this discussion may have is help people think about feeds a little differently, something will have been achieved. Thanks again for participating, Henry Story http://bblfish.net/blog/ [1] http://en.wikipedia.org/wiki/Irrational_numbers#Another_proof
Re: Atom, files and directories: what it's all about
On 29 Nov 2005, at 00:31, Luke Arno wrote: On 11/28/05, Ernest Prabhakar [EMAIL PROTECTED] wrote: Hi Henry, On Nov 23, 2005, at 3:22 AM, Henry Story wrote: A few improvements of atom over directories is that our feed can contain not just the current version of an entry, but all previous versions as well, which I think I remember was a feature supported by the vms file system. Interesting. It reminds me of a thought I had a while ago: would it be possible to emulate 80% of WebDAV by using HTTP + Atom? I think that is very much the idea. If you check what is going on on the atom protocol group you will find that they are moving in that direction http://bitworking.org/projects/atom/ Would we also need some sort of list structure, a la XOXO? http://microformats.org/wiki/xoxo Yup, but Atom Feed _is_ a list format. :-) Mhh. An Atom feed is a *Set* of entries. Not a list of entries. The entries are not ordered in any particular way in a feed. That is stated in the spec section 4.1.1 [[ This specification assigns no significance to the order of atom:entry elements within the feed. ]] In this sense it is again like the files in a directory. You can sort them different ways using options to the ls command, or if you have a graphical browser by clicking the different columns, but there is no objectively better order than another. In html one could perhaps represent them as un unordered list, which is perhaps what the xoxo people intend. You should check out some of the recent introspection discussion that went on over on Atom Pub. - Luke - Luke
Atom, files and directories: what it's all about
I suppose I am kind of slow in some ways. Perhaps everyone has realized this all along. But the relation between atom and a file system has just struck me forcefully recently. REST does not have the notion of a directory hierarchy. You may think it does because urls have slashes in them, and because you can browse the file system in a web browser. But really you are just lucky that most people use hierarchical file systems to construct their urls. The pages you get back if you point your browser to something like http://bblfish.net/bloged/ is an html human readable representation of the contents of a directory. What is a feed? It is a machine readable representation of the RESTful equivalent of a directory. What is an entry? It is the machine readable representation of the RESTful equivalent of a file. Directories contain files. Feeds contain entries. Files contain 'content'. Entries contain content too. When you type 'ls -ali' in a directory bash-2.03$ ls -ali total 61 2705932 drwxr-xr-x 3 hjs vuser512 Nov 22 16:10 ./ 2662433 drwxr-xr-x 34 hjs vuser 1024 Nov 22 16:10 ../ 2705933 -rw-r--r-- 1 hjs vuser 2059 Nov 22 16:10 BlogEd.jnlp 2705934 -rw-r--r-- 1 hjs vuser 49674 Nov 22 16:10 BlogEd.tiff 2705935 drwxr-xr-x 2 hjs vuser 1024 Nov 22 16:10 lib/ you get all kinds of metadata about the directory '.', and about the files in the directory. The first number is the inode, which is a little like the src url of the content. Same when you look at a basic feed ?xml version=1.0 encoding=utf-8? feed xmlns=http://www.w3.org/2005/Atom; 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 entry titleAtom-Powered Robots Run Amok in France/title link href=http://example.org/2003/12/13/atom03/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2005-11-13T18:30:02Z/updated summarySome text./summary type=xhtml xml:lang=en xml:base=http://diveintomark.org/; div xmlns=http://www.w3.org/1999/xhtml; piAfter a crash course in french cultural integration.../i/p /div /content /entry /feed The information is just presented differently. The xml makes it easier for machines to parse the content, as it deals with all the problems of unicode and separation of the data. Yes you can use sed and grep in unix, but you always will come across weird corner cases, such as when a file has a blank space in it, non ascii weird characters, ... Entries and Feeds are therefore both containers. In Unix we have known this all along: everything is a file. It is just that Directories are special kinds of files, that contain files themselves. So, as I have argued for a long time, Feeds are really types of Entries. Feeds can have images (icons) associated with them. In most end user file systems, so can folders. The atom group is working on adding the ability to add icons and images to entries too, then the symmetry will be complete. Entries are really containers for file metadata. As OSX is slowly moving to enabling file system metadata [1], % xattr --set name John file % xattr --set color red file % xattr --list file file color red name John so using the link relation one can add all types of metadata on feeds or entries entry titleAtom draft-07 snapshot/title link rel=alternate type=text/html href=http://example.org/2005/04/02/atom/ link rel=enclosure type=audio/mpeg length=1337 href=http://example.org/audio/ph34r_my_podcast.mp3/ idtag:example.org,2003:3.2397/id ... /entry The attribute value of the rel relation is in fact a url, as befits a web document text, and people can add whatever metadata they like there. By adding a feed link relation one allows feeds to point to feeds, which is the equivalent of directories inside directories. A few improvements of atom over directories is that our feed can contain not just the current version of an entry, but all previous versions as well, which I think I remember was a feature supported by the vms file system. Of course the URI id construct and the fact that the web does not have partitions, allows one to keep track of the identity of a file over the whole web, which simple inodes just cannot do. Henry Story [1] http://arstechnica.com/reviews/os/macosx-10.4.ars/7
Re: What is this entry about?
Just thought I'd mention that there is of course nothing in rdf that can stop anyone giving things names. So that the blank node could be given a name such as tag:example.com/versionid tag:example.com/versionid a :Entry; :title [ :value Atom-Powered Robots Run Amok; :type text/plain ]; :link [ :href http://example.org/2003/12/13/atom03; :rel iana:alternate ]; :id urn:uuid:1225c695-cfb8-4ebb--80da344efa6a; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value some text; :type text/plain ]. And so I suppose you could treat urn:uuid:1225c695-cfb8-4ebb--80da344efa6a as an Entry itself, give it a title, a link, an id, etc I am not sure this makes sense. I have formalised this doubt in the Atom-OWL ontology by the following statement: :Version a owl:Class; rdfs:comment Metadata about the state of a resource with given :id at an :updated time.@en; rdfs:subClassOf [ owl:complementOf :Id ]. Since :Entry and :Feed are subclasses of :Version, that means that Entries or feeds cannot be ids. Perhaps that is too harsh. Henry Story On 12 Nov 2005, at 12:48, Henry Story wrote: The way we got around this in Atom/OWL is to make the entry itself a blank node, with atom:id being a property of it. The unique identification of the entry node being provided by the combination of the id, updated (and some other stuff - multiple language support is a complication). Yes. The correct way to model it is therefore [] a :Entry; :title [ :value Atom-Powered Robots Run Amok; :type text/plain ]; :link [ :href http://example.org/2003/12/13/atom03; :rel iana:alternate ]; :id urn:uuid:1225c695-cfb8-4ebb--80da344efa6a; :updated 2003-12-13T18:30:02Z^^xsd:dateTime; :summary [ :value some text; :type text/plain ]. ie, as Danny says, to apply the :title, :link, etc relations to a blank node of type :Entry. By defining :id as functional we allow different blank node :Entry s to have the same id, and so the contradiction we had before no longer exists. This is not so complicated really, it is just easy to be mislead by the 'id' word and think that it must be a strong identity relation, rather than a weaker one. (ie, to think that the relation is not just functional, but also inverse functional symmetric and transitive)
Re: What is this entry about?
On 12 Nov 2005, at 10:26, Danny Ayers wrote:
[snipped a very good conversation]
(I've cc'ed the atom-owl list, this is certainly in scope over there).
I think Bill's right about the direction being the issue, and has
probably got the right answer with adding another property to the
entryURI, but there's a fair bit of devil in the detail.
There's a slight mismatch between Atom's id and resource
identification in the RDF sense (Henry, you've looked at this hardest
- please correct me if I'm wrong). Entries can appear with different
values but the same id, e.g.
[[
If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed Document, they represent the same entry. Their atom:
updated timestamps SHOULD be different.
]] 4.1.1
So if atom:id is treated as the entry resource URI then in a literal
RDF interpretation of the Atom spec you either end up with information
loss, older versions of the entry ceasing to exist (which doesn't
really work with either Atom or the RDF model) or contradictions, e.g.
more than one content value for an entry when the properties of the
resources are lined up together.
yes. Very well explained. I'll just fill out the details again below,
for those who may be new to this [1]. If you take the example
entry
titleAtom-Powered Robots Run Amok/title
link href=http://example.org/2003/12/13/atom03/
idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
updated2003-12-13T18:30:02Z/updated
summarySome text./summary
/entry
you DON't want to model it as:
urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
:title Atom-Powered Robots Run Amok^^xsd:string;
:updated 2003-12-13T18:30:02Z^^xsd:date .
because if a feed contained a correction of the above entry say
entry
titleAtom-Powered Robots Run Amok in France/title
link href=http://example.org/2003/12/13/atom03/
idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
updated2005-12-13T18:30:02Z/updated
summarySome updated text./summary
/entry
then you would have
urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
:title Atom-Powered Robots Run Amok in France^^xsd:string;
:updated 2005-12-13T18:30:02Z^^xsd:date .
And so by smushing the graph you would end up with something that was
not
very useful such as
urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
:title Atom-Powered Robots Run Amok^^xsd:string;
:title Atom-Powered Robots Run Amok in France^^xsd:string;
:updated 2003-12-13T18:30:02Z^^xsd:date .
:updated 2005-12-13T18:30:02Z^^xsd:date .
And you would no longer know which title belonged with which updated
time
stamp.
The way we got around this in Atom/OWL is to make the entry itself a
blank node, with atom:id being a property of it. The unique
identification of the entry node being provided by the combination of
the id, updated (and some other stuff - multiple language support is a
complication).
Yes. The correct way to model it is therefore
[] a :Entry;
:title [ :value Atom-Powered Robots Run Amok;
:type text/plain ];
:link [ :href http://example.org/2003/12/13/atom03;
:rel iana:alternate ];
:id urn:uuid:1225c695-cfb8-4ebb--80da344efa6a;
:updated 2003-12-13T18:30:02Z^^xsd:dateTime;
:summary [ :value some text;
:type text/plain ].
ie, as Danny says, to apply the :title, :link, etc relations to a
blank node
of type :Entry. By defining :id as functional we allow different
blank node
:Entry s to have the same id, and so the contradiction we had before no
longer exists.
This is not so complicated really, it is just easy to be mislead by
the 'id' word
and think that it must be a strong identity relation, rather than a
weaker one.
(ie, to think that the relation is not just functional, but also
inverse functional
symmetric and transitive)
This seems to work pretty well for most purposes - an
application could either take the forget older entry versions
processing model, or accumulate all the versions.
yes.
But when it comes to
saying what the entry in about, I think you'd almost certainly expect
all *versions* of an entry to be about the same thing, so the subject
of the statement would be the id URI. This is easy enough in RDF (the
id is a resource), but it's not obvious how this migght be expressed
in Atom syntax.
For a long time I wanted to put properties on the id when I felt they
were necessary properties of the thing. The problem as James Gosling
reminded me [2] is that defining essential properties of things can
be quite tricky. And I suppose that many a document that started about
one thing ended up being about something quite different.
So I would tend initially towards conservatism, and not put any property
on the id. One could of course invent/discover such a property
say :idabout
that would have the following rule associated with it
{ ?id
Re: Is Atom Broken?
Well it clearly should be able to be generated someplace other than the server. That was one major point of having ids: to be able to allow entries to be moved from one server to another whilst allowing them to keep the same id. In order for that to work the server needs to accept the id given to it by the client. Henry On 1 Nov 2005, at 15:20, Joe Gregorio wrote: On 10/31/05, Luke Arno [EMAIL PROTECTED] wrote: That is a tall order and I think it requires some discussion as to how. :-) I would like to start with atom:id. Should it be generated client side?
Re: FYI: hAtom
, I do need to represent the resolved hierarchy of feeds in the context of the XHTML document. The whole point of supporting a microformat in this way would be to be able to provide a reasonable means to parse/scrape the XHTML to be able to make sense of the hierarchy of hAtom representations that were generated from originally walking the root Atom document feed when the document got generated, to be able to extract nested feeds, and the other microformat types that might have been rendered within the context of feed entries. Except for those restrictions imposed by the microformat community and the hAtom spec in particular do you see potential issues with what I want to do here? Maybe there are some issues with XHTML ids or with hAtom not being able to clearly delineate itself that I am not seeing. I am a little new to microformats myself. Me too. RDF and OWL are even newer to me. My concerns with such a solution extend beyond whether it is technically doable into whether it meshes with the intent of these intersecting efforts (OWL, microformats, CSS, etc.). This idea fits very well with how I want to use Atom and microformats but it could introduce grief to others who want to play in my sandbox. Scott On 10/28/05, Henry Story [EMAIL PROTECTED] wrote: On 28 Oct 2005, at 13:10, Danny Ayers wrote: Hi Scott, Henry (cc'ed) - see below, On 10/28/05, Scott Anderson [EMAIL PROTECTED] wrote: Danny, I have been emailing David Janes asking him to preserve the viability of recursively embedding an hAtom feed within the contents of another feed's entry. I can make use of such a feed hierarchy to provide the semantic contexts (URIs included) that I was looking for. Microsoft's proposal for extending RSS/Atom feeds to model them as ordered lists appears to fit very well with this modeling of XHTML documents (and their presentation) as lists of lists. True. I have not been following this microsoft proposal. Any pointers? Looking around I found this: http://msdn.microsoft.com/windowsvista/building/rss/ simplefeedextensions/ But I am not aware of your use case. I think this implementation of feed=list=context=template hierarchies is much cleaner and more functional than what OPML+XSL or XOXO could effectively provide. I am convinced that the humans I have worked with would have a hard time consuming or producing XOXO markup. Heh, I know what you mean. I have only had time to do a brief overview of what you guys are doing with Atom/Owl work. My hope is that I can apply it and some simple OWL models to get me some syndicated portlets that spit out microformats within hierarchies of hAtom semantic contexts. Do you see any pitfalls that I may have overlooked? It sounds reasonable, but there may well be pitfalls ;-) Henry has looked pretty hard at the feed-hierarchies idea, if I remember correctly the main objections to this approach on the atom-syntax list were that it would make the parsing a bit harder. But from the XHTML point of view, where as you say lists can be hard to parse anyhow, maybe it would make sense. I don't know, maybe the only way of finding out how feasible this would be, would be to try a bit of code... Henry - thoughts? I am a little new to microformats myself. One way to get clear on your problem would be to try to use the latest AtomOwl [1] ontology and write out an example of what you want to do in n3. There are already 2 examples there. The Atom Syntax has many restrictions that are not shared by the ontology, as the syntax is designed to be easily parsed with xslt type tools, whereas the ontology is just trying to describe what we are speaking about. Once we work out what we are speaking about, it is then possible to decide what the best presentation of that is. I also find that by writing things out in N3 one gets a lot clearer about what the problem is. Henry [1] http://bblfish.net/work/atom-owl/2005-10-23/ Cheers, Danny. -- http://dannyayers.com
Re: Sponsored Links and other link extensions
On 24 Oct 2005, at 22:59, A. Pagaltzis wrote: * Antone Roundy [EMAIL PROTECTED] [2005-10-24 22:35]: Interesting. Filling an attribute with a list of URIs doesn't really appeal to me though. +100 (me and all my co-voting cats) How about this: link rel=enclosure type=audio/mpeg href=http://example.com/ file.mp3 xml:id=x-file altlink:mirror href=http://www2.example.com/file.mp3; / altlink:mirror href=http://www3.example.com/file.mp3; / /link It’s a lot more verbose and you have to fiddle with nesting. What do you get in return? “It looks more XMLish”? yes!? We are using xml! Sounds good, but you may have noticed above that I used a prefix not specific to enclosures--there's no reason to tie this all to one particular type of link (nor to make it look as if it were tied to one specific link type). So the other link might, for example, be: I don’t know if striving for generality in this fashion without a practical need is worthwhile. It smells of architecture astronautics for a reason I can’t particularly pinpoint. So maybe my instinct is wrong. maybe :-) A million cats can't be wrong. Note that I changed alternative-to to primary just because it's shorter and one word. Works for me. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
icon and logo on entry
I'd like to propose an extension that would allow something very much like icon and logo to be added to an entry, the way it currently is allowed on a feed. I have been publishing entries like this for over a year now [1], and so has James Gosling [2], and other users of BlogEd. It would be really nice to keep this semantic information in the feed somehow. Perhaps something like: feed xmlns=http://www.w3.org/2005/Atom; 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 logo./Image1-large.jpeg/logo icon./Image1-small.jpeg/icon entry titleAtom-Powered Robots Run Amok/title ext:logo./Image5-large.jpeg/logo ext:icon./Image5-small.jpeg/icon link href=http://example.org/2003/12/13/atom03/ idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id updated2003-12-13T18:30:02Z/updated summarySome text./summary /entry /feed Though from what I have said in other posts about relative uris in extension elements I suppose it would be better to have a new link type. Any ideas? Henry [1] http://bblfish.net/blog/ http://blogs.sun.com/roller/page/bblfish/ [2] http://blogs.sun.com/roller/page/jag/
Re: icon and logo on entry
Oh I think I get it now. You want to specify the logo and icon of a
resource
on the other side of a link.
So generalizing the suggestion:
entry
titleAtom-Powered Robots Run Amok/title
link rel=logo href=/Image5-large.jpeg/
link rel=icon href=/Image5-small.jpeg/
link href=http://example.org/2003/12/13/atom03;
link rel=logo href=http://example.org/2003/12/13/
atom03-large.jpeg/
link rel=icon href=http://example.org/2003/12/13/
atom03-small.jpeg/
/link
idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
updated2003-12-13T18:30:02Z/updated
summarySome text./summary
/entry
Makes sense to me.
Henry
http://blogs.sun.com/roller/page/bblfish/
On 25 Oct 2005, at 22:23, Henry Story wrote:
On 25 Oct 2005, at 22:08, James M Snell wrote:
I've been wanting to do the same thing for link elements.
Nice :-)
Let's propose a single solution:
entry
x:logo type={media-type}{url}/x:logo
x:icon type={media-type}{url}/x:icon
link
x:logo type={media-type}{url}/x:logo
x:icon type={media-type}{url}/x:icon
/link
/entry
Is the above a single solution, or two solutions? I can't quite
tell the
difference.
Would they (it?) be equivalent to the following:
entry
titleAtom-Powered Robots Run Amok/title
link rel=logo href=/Image5-large.jpeg/
link rel=icon href=/Image5-small.jpeg/
link href=http://example.org/2003/12/13/atom03/
idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
updated2003-12-13T18:30:02Z/updated
summarySome text./summary
/entry
I would think the media type is very much optional here.
Both elements should follow the exact same rules as the existing
atom:logo and atom:icon elements.
Do you mean rules, or do you mean semantics? (ie: we just copy and
paste the text
from the atom syntax doc, replacing feed with entry)
Henry
- James
Henry Story wrote:
I'd like to propose an extension that would allow something very
much like
icon and logo to be added to an entry, the way it currently is
allowed on a feed.
I have been publishing entries like this for over a year now [1],
and so has
James Gosling [2], and other users of BlogEd. It would be really
nice to keep
this semantic information in the feed somehow.
Perhaps something like:
feed xmlns=http://www.w3.org/2005/Atom;
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
logo./Image1-large.jpeg/logo
icon./Image1-small.jpeg/icon
entry
titleAtom-Powered Robots Run Amok/title
ext:logo./Image5-large.jpeg/logo
ext:icon./Image5-small.jpeg/icon
link href=http://example.org/2003/12/13/atom03/
idurn:uuid:1225c695-cfb8-4ebb--80da344efa6a/id
updated2003-12-13T18:30:02Z/updated
summarySome text./summary
/entry
/feed
Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new
link type.
Any ideas?
Henry
[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/
Re: New Link Relations -- Last Call
I agree self would do well. But it is true that it's current definition is a little vague. I don't suppose one can refine it in a way consistent with its current definition? In any case this all looks good to me. As soon as we agree on the names, I will implement these links in BlogEd, so that the web server can keep a complete history of published changes. What would I need to add to my feed to make it clear that I my feed is incremental (I think that's what my feed would be)? Henry On 24 Oct 2005, at 10:37, Stefan Eissing wrote: Am 23.10.2005 um 23:34 schrieb Mark Nottingham: On 23/10/2005, at 1:04 PM, Peter Robinson wrote: I prefer 'subscribe' because it better describes the meaning and intention behind the link, but I can live with 'current' if that is the consensus. Well, Tim seemed to have a pretty strong -1 on 'subscribe', whereas you say you can live with 'current'. So, at this point it looks like 'current', unless other people come forward. I flirted with recent briefly; anybody strongly like that one? Maybe it is clear to everyone but me...however i do not see the damage done by using rel=self instead of inventing a new relation. Could someone bother to explain that? I know the definition in the format spec says it points to an equivalent resource, but it also says that This is the preferred URI for retrieving Atom Feed Documents representing this Atom feed. I probably do miss something important here, but a) equivalent resource says either nothing or lets you enter a mine field while roy t. machine guns you b) representing this Atom feed requires some king of dualistic thinking: the whole Atom feed is composed of several Atom feed documents which are linked with prev and (maybe) next relations. self points to the URI for the overall feed and has the same value in all chained feed documents (or feed chunks as i would call them) Can I convince anyone to enter the land where an Atom feed is composed of one or more Atom feed documents? Cheers, Stefan
Re: New Link Relations -- Ready to go?
+1 to all too. On Fri, 21 Oct 2005, Eric Scheid wrote: Date: Fri, 21 Oct 2005 10:47:57 +1000 From: Eric Scheid [EMAIL PROTECTED] To: Atom Syntax atom-syntax@imc.org Subject: Re: New Link Relations -- Ready to go? +1 to all
Re: Feed History -04
My laptop broke down so I am having touble following all of this thread, but I agree that next, prev, ... should just suggest a linked list. There should then be special links for hist-prev, hist-next, ... that are in rdf terms sub-properties of prev, next, etc... On the atom-owl mailing list we are working on a very faithful onotology to the atom-syntax, that would allow this sub-property relation to be clearly stated. This keeps everything very nicely open, allowing many specialised semantics of the next, prev, style to be created. Henry On Mon, 17 Oct 2005, James M Snell wrote: Date: Mon, 17 Oct 2005 12:31:38 -0700 From: James M Snell [EMAIL PROTECTED] To: Robert Sayre [EMAIL PROTECTED] Cc: Byrne Reese [EMAIL PROTECTED], Eric Scheid [EMAIL PROTECTED], Atom Syntax atom-syntax@imc.org Subject: Re: Feed History -04 Robert Sayre wrote: On 10/17/05, Byrne Reese [EMAIL PROTECTED] wrote: next and previous are as James points out, orthogonal to ordering. The debate as to whether the next set goes backwards or forwards in time is not about the use of the terms next and previous, it is about the default sort order of a result set. Fully agree. Let's use what MarkP wrote down over a year ago, and stop debating the nature of adjacency and ordering as it relates time and archives. Are there any technical problems with the elements in this feed: http://diveintomark.org/xml/2004/03/index.atom ;-) Woo hoo! Robert and I agree on something ;-) Debating how the entries are organized is fruitless. The Atom spec already states that the order of elements in the feed has no significance; trying to get an extension to retrofit order-significance into the feed is going to fail... just as I discovered with my Feed Index extension proposal. * Next/Prev/Start/Subscribe defines a linked list of feed documents and/or entry documents and says absolutely nothing about the ordering of the entries. * Next/Prev/Start/Subscribe should be defined in their own specification that is not bound to Feed History * Feed History (if MarkN wishes it so) should normatively reference the Next/Prev/Start/Subscribe extension spec I do believe that a last link relation would be helpful for completeness and I do believe the use cases are there (e.g. search results, etc) but I am ok with dropping that for now as it can easily be defined later once the use cases do become more prominent. Over the next week I'll see if I can draft up the spec. I'll use what MarkP put together as the basis for what I write up and submit. - James
Re: Feed History -04
I am ok with next, prev, ... but I suppose I do have a question that is similar to Marks: how do I know in what order the results are listed? Are they in historical order? Are these feeds grouping entries in alphabetical order, in inverse historical order? Perhaps in alphabetical order of author,... Again next, prev, first, last deal very well with paging. how do we specify the order? Is this related to the query? Should there be a default order for subscription feeds? Should the ordering information be specified in the feed? In rdf we could say things like iana:historicalNext a owl:ObjectProperty; rdfs:subPropertyOf iana:next; rdfs:comment a historically ordered next relation . and then use historicalNext for the particular historical ordering that we need to archive our feeds. This would allow processors who do not understand or care about the historical ordering to still walk through the linked list of feeds. Henry Ps. writing from Italy http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/ On Sat, 15 Oct 2005, Mark Nottingham wrote: Date: Sat, 15 Oct 2005 20:45:35 -0700 From: Mark Nottingham [EMAIL PROTECTED] To: Eric Scheid [EMAIL PROTECTED] Cc: Atom Syntax atom-syntax@imc.org Subject: Re: Feed History -04 OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? On 15/10/2005, at 7:25 PM, Eric Scheid wrote: On 16/10/05 6:54 AM, Mark Nottingham [EMAIL PROTECTED] wrote: Can you walk me through a use case where this would be desirable? E.g. what would the subscription URI be, would any of the entries be updated, and how if so? In what scenario would having a closed set feed be useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed History -04
I am ok with next, prev, ... but I suppose I do have a question that is similar to Marks: how do I know in what order the results are listed? Are they in historical order? Are these feeds grouping entries in alphabetical order, in inverse historical order? Perhaps in alphabetical order of author,... Again next, prev, first, last deal very well with paging. how do we specify the order? Is this related to the query? Should there be a default order for subscription feeds? Should the ordering information be specified in the feed? In rdf we could say things like iana:historicalNext a owl:ObjectProperty; rdfs:subPropertyOf iana:next; rdfs:comment a historically ordered next relation . and then use historicalNext for the particular historical ordering that we need to archive our feeds. This would allow processors who do not understand or care about the historical ordering to still walk through the linked list of feeds. Henry Ps. writing from Italy http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/ On Sat, 15 Oct 2005, Mark Nottingham wrote: OK, but that still leaves us with the question below -- who's doing the paging, and why is it useful to have multiple ways around the thing? On 15/10/2005, at 7:25 PM, Eric Scheid wrote: On 16/10/05 6:54 AM, Mark Nottingham [EMAIL PROTECTED] wrote: Can you walk me through a use case where this would be desirable? E.g. what would the subscription URI be, would any of the entries be updated, and how if so? In what scenario would having a closed set feed be useful? An archive for a blog that is no longer being updated? An archive of entries pertaining to an event with a fixed endpoint? A discussion forum that has been closed. How are implementations supposed to use this information? Stop polling the feed? Consider its items immutable? I'm concerned if something so innocent-looking as last has these sorts of implications. perhaps a better example would then be a feed of search results, which at any time of query is a finite and closed set, and also designed to be paged through. e. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Re: Feed History -04
This looks good. Is the 'first' the feed document that changes, whereas 'next' and 'last' point to the archives? (in a feed history context?) Henry On Fri, 14 Oct 2005, James M Snell wrote: The way I look at this is in terms of a single linked list of feeds. The ordering of the entries within those feeds is irrelevant. The individual linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete (e.g. lists,etc). Simply because a feeds are linked, no assumption should be made as to whether or not the entries in those feeds share any form of ordered relationship. +1 link rel=first / is the first feed in the linked list link rel=next / is the next feed in the linked list link rel=previous / is the previous feed in the linked list link rel=last / is the last feed in the linked list. Terms like top, bottom, up, down, etc are meaningless in this model as they imply an ordering of the contents. For feed history, it would work something like: feed ... link rel=self href=...feed1 / link rel=next href=...next / link rel=last href=...feed3 / ... /feed feed ... link rel=self href=...feed2 / link rel=previous href=...feed1 / link rel=next href=...feed3 / link rel=first href=...feed1 / link rel=last href=...feed3 / ... /feed feed ... link rel=self=href=...feed3 / link rel=previous href=...feed2 / link rel=first href=...feed1 / ... /feed - James Mark Nottingham wrote: At first I really liked this proposal, but I think that the kind of confusion you're concerned about is unavoidable; the terms you refer to suffer bottom-up vs. top-down. I think that defining the terms well and in relation to the subscription feed will help; after all, the terms don't surface in UIs, so it should be transparent. On 14/10/2005, at 10:37 AM, Antone Roundy wrote: Which brings me back to top, bottom, up and down. In the OpenSearch case, it's clear which end the top results are going to be found. In the syndication feed case, the convention is to put the most recent entries at the top. If you think of a feed as a stack, new entries are stacked on top. The fact that these terms are less generic and flexible than previous and next is both an advantage and a disadvantage. I think the question is whether it's an advantage in a significant majority of cases or not. What orderings would those terms not work well for? -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Re: Feed History -04
It occurred to me that I should think a little more before speaking. There seems to be a history of the atom spec here: http://bitworking.org/projects/atom/ I could not find the prev link in any of the specs. So I guess I was mistaken. But I also always thought of prev and next as being very good candidates for the link element. I never raised my voice against the move at the time because I assumed most decisions on this list were good ones. There is one reference to prev and next here: http://www.intertwingly.net/wiki/pie/LinkTagMeaning Henry On 9 Oct 2005, at 10:47, Henry Story wrote: I believe it was part of atom 0.3, and for some complex reason I never bothered trying to understand someone decided it should be moved over to the protocol side of things. Probably just because the debate was taking up too much time... So yes. 'prev' and 'next' have always been intended to be there in the link element... Henry On 9 Oct 2005, at 10:39, James Holderness wrote: Following up on the idea of using atom:link instead of fh:prev, I recently came across an old article by Mark Pilgrim on XML.com (http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the atom:link element and the various rel attributes it supports. He specifically brings up the issue of feed history and using next and prev to link archives together. It sounded to me as if he was talking about an existing feature in the spec - it wasn't like he was proposing it as a new idea. So was this something that used to be part of an old version of the spec that was later removed? Or was this an early proposal that was never accepted into the spec? Also of interest: there's a link from that article to his archives on diveintomark.org which actually include next and prev links in the feed. I'm almost inclined to add support for that just so I can access those old posts. There used to be some excellent articles on his site.
Re: Entries in multiple language
On 28 Sep 2005, at 14:48, Reto Bachmann-Gmür wrote: [snip lots of interesting stuff, to get to later] Note that the first two entries share the same value of atom:updated, this is a SHOULD-Level violation of section 4.1.1. I think the spec should allow multiple entries with the same timestamp iff they differ by language and/or content-type. In multilingual countries like Switzerland it is required (as for laws) or at least a matter of political correctness (as for press releases) for some publications to be published at the same time in all language versions. Why not publish content negotiated atom feeds, so that the French version of the feed only contains french entries, the German version only German entries, the Italian one only Italian ones, and the Romansh one only Romansh entries? Then the user would subscribe to the feed serving the entries in the language preferred by the author. Of course since in Switzerland the German, French and Italian representations of the feed have to appear simultaneously they will each contain entries with identical ids and identical atom:updated time stamps. This would not contradict the atom spec which mentions only that in a particular feed document two entries with the same id should not have the same updated time stamp. It is something on the other hand that an ontology of atom would have to be careful about (or a database consuming atom feeds), as it would have to take into account the possibility of multiple language versions of the same update of an entry. Henry Story The following two entries are in a feed entry xmlns=http://www.w3.org/2005/Atom; xml:lang=de titleAsylgesetzrevision - Aus humanitärer Sicht inakzeptabel! /title link rel=self type=text/html hreflang=de href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=application/rdf+n3 hreflang=de href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=text/html hreflang=fr href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=application/rdf+n3 hreflang=fr href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=enclosure length=92678 title=Presserohstoff href=http://www.osar.ch/ 2005/09/27/050927_asylgnr_presserohstoff_/ idhttp://www.osar.ch/2005/09/27/pm_asylg-revision/id updated2005-09-27T11:00-01:00/updated published2005-09-27T11:00-01:00/published author namepro/name urihttp://osar.ch/aslum-rights/uri email[EMAIL PROTECTED]/email /author summary type=xhtml xml:base=http://www.osar.ch/; div xmlns=http://www.w3.org/1999/xhtml; Der Nationalrat hat heute praktisch allen Verschärfungsvorschlägen des Ständerates zum Asylgesetz zugestimmt. Der verfassungswidrige Nothilfestopp blieb chancenlos. Die SFH ist sehr enttäuscht über den Ausgang der Beratung. Das neue Gesetz opfert den Schutz von Verfolgten zugunsten von unverhältnismässiger Missbrauchsbekämpfung. Damit ist das Referendum unausweichlich. /div /summary /entry entry xmlns=http://www.w3.org/2005/Atom; xml:lang=fr generator uri=http://www.example.com/; version=1.0 Example Toolkit /generator titleRevision de la loi sur l'asile - Inacceptable sur le plan humain/title link rel=self type=text/html hreflang=fr href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=application/rdf+n3 hreflang=fr href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=text/html hreflang=de href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ link rel=self type=application/rdf+n3 hreflang=de href=http://www.osar.ch/2005/09/27/pm_asylg-revision/ !-- Omiting the length attribute as the enclosure is not yet available in french, a temporary SHOULD-level violation! -- link rel=enclosure title=Documentation href=http://www.osar.ch/ 2005/09/27/050927_asylgnr_presserohstoff_/ idhttp://www.osar.ch/2005/09/27/pm_asylg-revision/id updated2005-09-27T11:00-01:00/updated published2005-09-27T11:00-01:00/published author namepro/name urihttp://osar.ch/aslum-rights/uri email[EMAIL PROTECTED]/email /author summary type=xhtml xml:base=http://www.osar.ch/; div xmlns=http://www.w3.org/1999/xhtml; Le Conseil national a approuvé aujourd’hui pratiquement toutes les aggravations proposées par le Conseil Fédéral dans le cadre de la révision de la loi sur l’asile. L’exclusion de l’aide de première nécessité, contraire à la Constitution, a été rejetée. L’OSAR se montre profondément déçue par l’issue des débats. La nouvelle loi sacrifie la protection des personnes persécutées sur l’autel d’un combat disproportionné contre les abus. Le référendum apparaît dès lors inévitable. /div /summary /entry One hour later an important error in the french version gets fixed (s
Re: ACE - Atom Common Extensions Namespace
I really like the ACE proposal, and I think the name is a good one too :-) It can't harm to have this option on the table now. No one is forced to use it. But I think it will have a few positive effects: - proposals that use it will have a cool ace namespace name - proposals that want to use the name will perhaps work a little harder to coordinate with other proposals on the table, which can't be a bad thing. Synergies between different proposals might be found thereby reducing the workload on implementors. - The namespace will act like a stamp of approval. It will be an indication that there is some consensus behind the proposal, and that things will play nice together This is not limiting anyone in any way. Proposals that want to use the dublin core, foaf or other namespaces should have no trouble using them. Proposals can also decide to use their own name space like the current feed history namespace. Henry Story On 3 Oct 2005, at 07:15, 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. And that is a problem that the end user won't to make himself all alone then. Since every end user is bound to come up with his own idea of how to lump things together, thereby creation an explosion of private lumps, this should in the end also reduce the workload on implementors. 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. Nothing is lost. All those benefits remain, as I said above. The atom spec has been designed to be open, the ace proposal will not and could not change that. A much better thing would be to wait a year or two and see if there's a need for such a beast. All these little proposals we have now indicates that we should work preventatively and at least put the option on the table for proposers to consider. And, the idea of an XML namespace backed by an IANA registry is a little bit twisted, considering the W3C and IETF's philosophies about these things ;) Cheers, On 01/10/2005, at 10:54 PM, James M Snell wrote: As I've been going through the effort of defining a number of Atom extensions, I've consistently come back to the thought that it would be interesting to explore the creation of a Common Extensions Namespace under which multiple standardized extensions can be grouped. I've written an initial draft of the concept but before I submit it as an Internet Draft, I'd like to get some feedback from the group. Please review the attached and let me know what you think. - James
Re: Feed History -04
I think this is good, but I would prefer the atom:link to be used instead of the fh:prev structure, as that would better fit the atom way of doing things. I also think it may be very helpful if we could agree on an extension name space that all accepted extensions would use, in order to reduce name space clutter. Henry On 7 Sep 2005, at 01:18, Mark Nottingham wrote: Feed History -04 is out, at: http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- history-04.txt Changes: - fh:stateful - fh:incremental, with appropriate changes in text - more explicit cardinality information - implications of fh:prev being an Absolute URI spelled out - more explicit white space handling - Acknowledgements section More information, including implementation details, at: http://www.mnot.net/blog/2005/09/05/feed_history -- Mark Nottingham http://www.mnot.net/
Re: Structured Publishing -- Joe Reger shows the way...
Is DOAP over Atom [1] an example of the type of solution you are suggesting James? That looks good. But what if I want to annotate an entry with some RDF? In a recent blog [2] I describe a cool bar in Zürich. I mention that I would also like to add to my feed information pertaining to the description. So I would like for example to say that my entry is about a particular bar, give the address of the bar, its geo location perhaps, that it has free wifi, and that it is very friendly. This would allow search engines to index much more structured information about the bar than they otherwise could. This would allow Google Maps for example to give a location to my feedback on their maps. In the DOAP over Atom type solution where the RDF is placed inside the content, there is then no more space to put the entry content itself. So I can either put the text entry into the content or the metadata. Where should the metadata go? Henry Story [1] http://www.codezoo.com/about/doap_over_atom.csp [2] http://blogs.sun.com/roller/page/bblfish/20050910 On 10 Sep 2005, at 01:51, James M Snell wrote: Bob Wyman wrote: I’ve written a blog post pointing to a wonderful demo of tools for doing structured publishing in blogs that Joe Reger has put together. Given that Atom has built-in support for handling much more than just the text/HTML that RSS is limited to, I think this should be interesting to the Atom community. http://bobwyman.pubsub.com/main/2005/09/joe_reger_shows.html What can we do with Atom to make the vision of Structured/Semantic publishing more real? bob wyman There really isn't anything we HAVE to do with Atom to make it suitable for Structured publishing. The format's content model is already more than adequate for this kind of thing. For instance, Joe Reger's software could easily stuff the XML data instances that conform to a logs XML Schema into the atom:content element while including the text description of the log into the atom:summary. The only thing that really needs to happen here is for someone to begin writing the code that makes this happen. - James
Re: Top 10 and other lists should be entries, not feeds.
+1 I completely agree with Bob again. Though my preference of course would be to put RDF in the content. RDF has structures for ordered lists. It probably has vocabularies for songs. It has vocabulary to specify the author of a work, etc... And with foaf you could also specify which of the artists was your friend. In short you can mix the different RDF vocabularies out there in well understood ways. For those of you new to RDF but au fait with Java, I have just written up a blog that should help explain exactly why RDF is so powerful: http://blogs.sun.com/roller/page/bblfish? entry=java_annotations_the_semantic_web In short: RDF can be mapped directly onto Java Beans. Just as Beans can be plugged together, so RDF markup can be plugged together. Welcome to the world of OO xml. Henry Story On 30 Aug 2005, at 07:49, 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. What is the problem? Why don’t folk see that lists are the stuff of entries – not feeds? Remember, “It’s about the entries, Stupid…” I think the reason we’ve got this pull to turn feeds into Lists is simply because we don’t have a commonly accepted “list” schema. So, the idea is to repurpose what we’ve got. Folk are too scared or tired to try to get a new thing defined and through the process, so they figure that they will just overload the definition of something that already exists. I think that’s wrong. If we want “Lists” then we should define lists and not muck about with Atom. If everyone is too tired to do the job properly and define a real list as a well defined schema for something that can be the payload of a content element, then why not just use OPML as the list format? What is a search engine or a matching engine supposed to return as a result if it find a match for a user query in an entry that comes from a list-feed? Should it return the entire feed or should it return just the entry/item that contained the stuff in the users’ query? What should an aggregating intermediary like PubSub do when it finds a match in an element of a list-feed? Is there some way to return an entire feed without building a feed of feeds? Given that no existing aggregator supports feeds as entries, how can an intermediary aggregator/filter return something the client will understand? You might say that the search/matching engine should only present the matching entry in its results. But, if you do that what happens is that you lose the important semantic data that comes from knowing the position the matched entry had in the original list- feed. There is no way to preserve that order-dependence information without private extensions at present. I’m sorry but I simply can’t see that it makes sense to encourage folk to break important rules of Atom by redefining feeds to be lists. If we want “lists” we should define what they look like and put them in entries. Keep your hands off the feeds. Feeds aren’t lists – they are feeds. bob wyman
Re: Top 10 and other lists should be entries, not feeds.
Mhh. Good point too. For some reason though, this is starting to make me think that a feed is an entry again... Henry On 30 Aug 2005, at 13:23, Graham wrote: How would this apply to the most problematic example of a list feed, the BBC news headline page: http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml Which has the top stories first (amongst other structure) and is a hell of a lot more usable in news readers that preserve order. Graham
Re: Top 10 and other lists should be entries, not feeds.
It's late here, but since I have been called... Clearly the order of the entries could not be deduced from the tags themselves. One would need to have an extra tag in there such as this position tag feed entry idtag:first-in-list/id ext:position1/position titleThe Graphes of Wrath/title update1 July 2005/udpated ... /entry ... /feed to specify the order of the entry. I think at the time I was talking in the context of that being proposed. Again it is late, but I think my idea of having a entry always stay at the same position was that I was thinking that from one week to another one could just change the content of the entry feed entry idtag:first-in-list/id ext:position1/position titleOf Mice and Men/title update8 July 2005/udpated ... /entry /feed So that one could still think of a feed as a sequence of changes to resources. One would then, I thought, not need to republish the whole list of entries, just those that changed from week to week. As a result there was I thought, no need for a stateful tag. But the problem with that suggestion was that it could not cope well with mistaken feed updates. So that if I mistakenly entered Of Mice and Men but I meant to enter The Restaurant at the End of the Universe then adding the following entry feed entry idtag:first-in-list/id ext:position1/position titleThe Restaurant at the end of the Universe/title update8 July 2005/udpated ... /entry /feed would tend to indicate that the change was insignificant, whereas a change of date would tend to indicate that the there was a new entry in first position. Some proposed that one should distinguish therefore between the update time of the entry and the update time of the object of the entry... Henry On 30 Aug 2005, at 23:35, Thomas Broyer wrote: 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: Don't Aggregrate Me
On 25 Aug 2005, at 15:45, Joe Gregorio wrote: On 8/25/05, James M Snell [EMAIL PROTECTED] wrote: Up to this point, the vast majority of use cases for Atom feeds is the traditional syndicated content case. A bunch of content updates that are designed to be distributed and aggregated within Feed readers or online aggregators, etc. But with Atom providing a much more flexible content model that allows for data that may not be suitable for display within a feed reader or online aggregator, I'm wondering what the best way would be for a publisher to indicate that a feed should not be aggregated? For example, suppose I build an application that depends on an Atom feed containing binary content (e.g. a software update feed). I don't really want aggregators pulling and indexing that feed and attempting to display it within a traditional feed reader. What can I do? First, on this scenario, I would be inclined to make the firmware an enclosure and not included base64. +1 definitely. But I still can see a scenario you might be serving up queries via Atom and those queries could be 'heavy'. There are, of course, several things you could do: 1. Cache the results. 2. Support ETags 3. Support ETags and 'fake' them so that they change only once a day, maybe once a week even. I would put the following as the most obvious solution 0. have the content link to the file either by using enclosures or content by reference such as content type=application/patch src=/patch.patch / There should be a golden rule: never place binary content in xml. It is ugly and completely unnecessary. Do we put base64 encoded stuff in html? No: that is why there are things like img src=... Henry There are undoubtedly others, but the more important part is that your 'do not aggregate' doesn't really solve the problem. I could, for example, take one of your heavy search feeds, convert it to HTML via XSLT and include that via iframe in my home page. *That* traffic is going to be a lot worse than an aggregator subscription and wouldn't fit the definition of 'aggregation'. -joe -- Joe Gregoriohttp://bitworking.org
Re: Don't Aggregrate Me
On 25 Aug 2005, at 17:06, A. Pagaltzis wrote: * Henry Story [EMAIL PROTECTED] [2005-08-25 16:55]: Do we put base64 encoded stuff in html? No: that is why there are things like img src=... img src=data:image/gif;base64,R0lGODlhAQABAIAAAP/// yH5BAEKAAEALAABAAEAAAICTAEAOw== / !!! That really does exist?! Yes: http://www.ietf.org/rfc/rfc2397.txt But apparently only for very short data fragments (a few k at most). And it does not give me anything very intersting when I look at it in either Safari or Firefox. Thanks for pointing this out. :-) :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Don't Aggregrate Me
Mhh. I have not looked into this. But is not every desktop aggregator a robot? Henry On 25 Aug 2005, at 22:18, James M Snell wrote: At the very least, aggregators should respect robots.txt. Doing so would allow publishers to restrict who is allowed to pull their feed. - James
Re: Don't Aggregrate Me
Yes, I see how one is meant to look at it. But I can imagine desktop aggregators becoming more independent when searching for information... Perhaps at that point they should start reading robots.txt... Henry On 25 Aug 2005, at 23:12, Walter Underwood wrote: I would call desktop clients clients not robots. The distinction is how they add feeds to the polling list. Clients add them because of human decisions. Robots discover them mechanically and add them. So, clients should act like browsers, and ignore robots.txt. Robots.txt is not very widely deployed (around 5% of sites), but it does work OK for general web content. wunder --On August 25, 2005 10:25:08 PM +0200 Henry Story [EMAIL PROTECTED] wrote: Mhh. I have not looked into this. But is not every desktop aggregator a robot? Henry On 25 Aug 2005, at 22:18, James M Snell wrote: At the very least, aggregators should respect robots.txt. Doing so would allow publishers to restrict who is allowed to pull their feed. - James -- Walter Underwood Principal Software Architect, Verity
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
On 22 Aug 2005, at 18:29, James M Snell wrote: Bill de hÓra wrote: As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. +1 Ok, this is absolutely fine. I'll go back through and update my various extension proposals to reflect this train of thought. - James
Re: Feed History -03
On 17 Aug 2005, at 00:14, Mark Nottingham wrote: On 16/08/2005, at 3:05 PM, Robert Sayre wrote: I suggested writing the next tag like this: link type=http://purl.org/syndication/history/1.0/next; href=./ archives/archive1.atom That's what I would do, too. Not my spec, though. Mainly so I could put a title in that said Entries from August or whatever. 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? Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? Clearly if the extensions themselves were to use only xlink:link elements that would be easy. (though atom itself does not give a good example by not following that principle). Is there a place that parsers can get information where they can automatically tell that an attribute is a xlink:link copycat? Or how do they tell that the content of an element is a URI? Can DTDs or RelaxNG files help? If they could help, would they be retrievable mechanically by a processor of xml to help it work out how to deal with relative references? Anyway to summarise: if you don't want to use the atom:link element then perhaps it would be best to use the xlink:link attributes. I have only read that spec quickly [1] but this would mean that the following fh:history xlink:href=./archives.archive1.atom would widely be understood to work with the xml:base. Henry Story [1] http://www.w3.org/TR/2001/REC-xlink-20010627/ This interpretation of extensions seems very fragile to me. -- Mark Nottingham http://www.mnot.net/
Re: Feed History -03
On 16 Aug 2005, at 02:19, Mark Nottingham wrote: On 15/08/2005, at 5:09 PM, Robert Sayre wrote: I'm interested in getting things working, not playing the syndication format advocacy game. Not sure how feed-history will work without a unique id. ? Sorry, you lost me there. Yes. If you were to take a subscription feed feed.atom and map it to a graph you might get something like this: _feed |id-- tag:myblog,2005/feed |---entry _ | |id- tag:myblog,2005/e1 | |---title--- first entry |--fh:next--- http://my.web/feed/history1.atom The graph of the history1.atom archive may be: _feed2 |id-- tag:myblog,2005/feed |---entry _ |id- tag:myblog,2005/e2 |---title--- another entry The role of id is to help us merge the two graphs. IE the point of the history tag is to help us think of the history.atom document as a continuation of the same document, or rather that they are both descriptions of the feed with id tag:myfeed,2005/feed. Merging the above two as simple graphs at most gives this tag:myblog,2005/feed |--1/id--- _feed | |---entry _ | | |id- tag:myblog,2005/e1 | | |---title--- first entry | |--fh:next--- http://my.web/feed/history1.atom |--1/id---_feed2 |---entry _ | |id- tag:myblog,2005/e2 | |---title--- another entry |--fh:next--- http://my.web/feed/history1.atom But what we really want is something like this: tag:myblog,2005/feed |---entry _ | |id- tag:myblog,2005/e1 | |---title--- first entry |---entry _ |id- tag:myblog,2005/e2 |---title--- another entry I think we require some form of inferencing beyond what is available in OWL to achieve this result. This could probably be achieved through some simple N3 rules. Henry Story
Re: Feed History -03
I think that in section 5. you should specify that the URI reference MUST NOT be relative or MUST BE absolute (if that is the proper W3C Architecture term). I agree with the point made by David Powell in the thread entitled More about extensions [1]. Given that we have this problem I was wondering whether it would not be better to use the link element as I think it permits relative references. Relative references really are *extreemly useful*. I tried to work without them in my BlogEd editor because the Sesame database folk mistakenly thought it was not part of RDF, and it caused me no end of trouble: all those problems vanished as soon as they allowed relative references. So if relative references are allowed in links perhaps the following would be better: link type=http://purl.org/syndication/history/1.0/next; href=./ archives/archive1.atom Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html On 15 Aug 2005, at 22:31, Mark Nottingham wrote: Draft -03 of feed history is now available, at: http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- history-03.txt Significant changes in this revision include: - add fh:archive element, to indicate that an entry is an archive - allow subscription feed to omit fh:stateful if fh:prev is present - clarified that fh doesn't add ordering semantics, just allows you to reconstruct state - cleaned up text, fixed examples, general standards hygiene There's going to be at least one more draft, as I neglected to acknowledge people who have made suggestions and otherwise helped so far. Sorry! -- Mark Nottingham http://www.mnot.net/
Re: Feed History -03
On 16 Aug 2005, at 21:00, Mark Nottingham wrote: I very much disagree; relative references should be allowable in simple extensions, and in fact the rationale that Tim gives is the reasoning I assumed regarding Atom extensions; if I had known that the division between simple and complex extensions would be used to justify a constraint on the use of context in simple extensions, I would have objected to it. The problem is that readers of your xml that wish to store your data in some form other than xml (relational database, triple store, object oriented database, prolog database,...), and that may not at the time of consumption know about your extension will save the content in text, which is all the spec says they should do. Since they don't at the time know the meaning of fh:prev and in particular that it should contain a URI they can't save the absolute URI it represents. All they will be able to save is relative uri which will be meaningless if the context of the original document is lost. If you're using something like RDF to model feeds, you already have a number of context-related issues to work through, this isn't an extra burden. The point of making extensions is that they should be interpretable or at least in part useable by parties that don't understand the extension. RDF has nothing to do with this. (Other than it having some very solid theoretical backing and so being very helpful in thinking about these issues, and also of it having solved quite a few years ago the problems that you are just discovering) I should explicitly allow relative URIs in fh:prev, though. -1 This is a question of the Atom spec saying that the content of a simple extension element is character data. Yet you are now wishing to put in relative references that have complex semantics not completely understandable without having the original context of the document they appear in. I know it may seem to the writer of an extension as if the meaning of his extension were clear as day, but this will not be the case to all consumers of your extension, and even if your extension becomes world famous, it certainly won't be true for all the other extensions that people will come up with. So I think we should be setting a good example in these first extensions we write. Henry Story Cheers, On 16/08/2005, at 11:35 AM, Henry Story wrote: I think that in section 5. you should specify that the URI reference MUST NOT be relative or MUST BE absolute (if that is the proper W3C Architecture term). I agree with the point made by David Powell in the thread entitled More about extensions [1]. Given that we have this problem I was wondering whether it would not be better to use the link element as I think it permits relative references. Relative references really are *extreemly useful*. I tried to work without them in my BlogEd editor because the Sesame database folk mistakenly thought it was not part of RDF, and it caused me no end of trouble: all those problems vanished as soon as they allowed relative references. So if relative references are allowed in links perhaps the following would be better: link type=http://purl.org/syndication/history/1.0/next; href=./ archives/archive1.atom Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html On 15 Aug 2005, at 22:31, Mark Nottingham wrote: Draft -03 of feed history is now available, at: http://www.ietf.org/internet-drafts/draft-nottingham-atompub- feed-history-03.txt Significant changes in this revision include: - add fh:archive element, to indicate that an entry is an archive - allow subscription feed to omit fh:stateful if fh:prev is present - clarified that fh doesn't add ordering semantics, just allows you to reconstruct state - cleaned up text, fixed examples, general standards hygiene There's going to be at least one more draft, as I neglected to acknowledge people who have made suggestions and otherwise helped so far. Sorry! -- Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/
Re: Feed History -03
On 16 Aug 2005, at 21:50, Robert Sayre wrote: On 8/16/05, Henry Story [EMAIL PROTECTED] wrote: On 16 Aug 2005, at 21:00, Mark Nottingham wrote: I very much disagree; relative references should be allowable in simple extensions, and in fact the rationale that Tim gives is the reasoning I assumed regarding Atom extensions; if I had known that the division between simple and complex extensions would be used to justify a constraint on the use of context in simple extensions, I would have objected to it. The problem is that readers of your xml that wish to store your data in some form other than xml (relational database, triple store, object oriented database, prolog database,...), and that may not at the time of consumption know about your extension will save the content in text, which is all the spec says they should do. Since they don't at the time know the meaning of fh:prev and in particular that it should contain a URI they can't save the absolute URI it represents. All they will be able to save is relative uri which will be meaningless if the context of the original document is lost. The app should store the relative URI, and it shouldn't lose the context. relative URI? The application we are speaking about knows nothing of a relative uri. All you have inside your Simple Extension Element is text! See the spec 6.4.1. An application that does not know your extension cannot know that the text inside your extension is to be interpreted as a relative uri. So what you are saying is that any application that wants to process atom with extension elements has to keep the full context of the document in which they found the extension element, even if the document is a 100s of Megabytes long, and even if there is only one extension element inside of it! Or take the case of code that wants to place the feed inside some other xml, which has a base element. What is it to do when it finds an extension element it does not understand? If you're using something like RDF to model feeds, you already have a number of context-related issues to work through, this isn't an extra burden. The point of making extensions is that they should be interpretable or at least in part useable by parties that don't understand the extension. It still is. No they are not! See the 2 examples above. This is a question of the Atom spec saying that the content of a simple extension element is character data. Yet you are now wishing to put in relative references that have complex semantics not completely understandable without having the original context of the document they appear in. Lots of extensions will be like this. What's one itunes extenstion without the others? :) ? In summary, I agree with Mark. You agree to accept the problems that go with his position, yes. But why bother when there clearly is an easy solution to the problem that works with the current atom format and which I outlined earlier, namely using the link element. I suggested writing the next tag like this: link type=http://purl.org/syndication/history/1.0/next; href=./ archives/archive1.atom This clearly allows relative uris (if I am not mistaken) without any of the problems we have with the simple extension elements. And it seems to be exactly this type of thing that the link element was designed to do. Henry Story http://blogs.sun.com/roller/page/bblfish/ Robert Sayre
Re: Expires extension draft (was Re: Feed History -02)
There is an interesting problem of how this interacts with the history tag. If you set an a feed feed expires.../expires entry/entry entry/entry /feed then what are you setting it on? Well not the document, clearly, as you have pointed out since HTTP headers deal with that. So it must be on the feed. And of course a feed is identified by its id. Now we have to make sure we avoid contradictions where different feed documents describing the same feed state that the feed has different expiry dates. Eg: the main feed-- feed expiresAugust 25 2006/expires idtag:example.com,2000/feed1/id entry/entry entry/entry history:previoushttp://example.com/archive1/history:previous /feed --- The above is a partial description of the feed tag:example.com,2000/ feed1 The history:previous link points to another document that gives us more information about that feed. ---the archive feed feed expiresAugust 15 2006/expires idtag:example.com,2000/feed1/id entry/entry entry/entry history:previoushttp://example.com/archive2/history:previous /feed --- Now of course we have a feed id with two expiry dates. Which one is correct? In graph terms we end up with something like this: tag:example.com,2000 |expires--August 25 2006 |expires--August 15 2006 |entry... |entry... |entry... |entry... One has the feeling that the expires relation should be functional, ie have only one value. This makes me think again that for what I was looking for (that the document in history:previous not change, so that one can work out when to stop fetching documents) can in fact be entirely be taken care of by the http expiry dates and cache control mechanism. Of course if this is so, I think it should be noted clearly in the history spec. ((btw. Is it easy to set expiry dates for documents served by apache?)) Henry Story On 10 Aug 2005, at 04:46, James M Snell wrote: This is fairly quick and off-the-cuff, but here's an initial draft to get the ball rolling.. http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt - James Henry Story wrote: To answer my own question [[ Interesting... but why have a limit of one year? For archives, I would like a limit of forever. ]] I found the following in the HTTP spec [[ To mark a response as never expires, an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. ]] (though that still does not explain why.) Now I am wondering if the http mechanism is perhaps all that is needed for what I want with the unchanging archives. If it is then perhaps this could be explained in the Feed History RFC. Or are there other reasons to add and expires tag to the document itself? Henry Story On 9 Aug 2005, at 19:09, James M Snell wrote: rules as atom:author elements. Here it is: http://www.intertwingly.net/wiki/pie/PaceCaching The expires and max-age elements look fine. I hesitate at bringing in a caching discussion. I'm much more comfortable leaving the definition of caching rules to the protocol level (HTTP) rather than the format extension level. Namely, I don't want to have to go into defining rules for how HTTP headers that affect caching interact with the expires and max-age elements... IMHO, there is simply no value in that. The expires and max-age extension elements affect the feed / entry on the application level not the document level. HTTP caching works on the document level. Adding max-age also means defining IntegerConstruct and disallowing white space around it. Formerly, it was OK as a text construct, but the white space issues change that. This is easy enough. Also, we should decide whether cache information is part of the signature. I can see arguments either way. -1. let's let caching be handled by the transport layer.
Re: More about Extensions
Sorry to note the obvious, but does this not sound so much like a good reason we should have engineered atom to *be* RDF? Is this not exactly one of the many problems that RDF sets out to solve? Henry Story On 10 Aug 2005, at 02:34, Tim Bray wrote: On Aug 9, 2005, at 5:11 PM, David Powell wrote: No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. Either the software understands the foreign markup, in which case it might recognize a relative URI, in which case it should apply the correct base URI, or it doesn't, in which case everything in the foreign markup is just a semantics-free string. The problem could hypothetically arise when someone extracts properties from the foreign markup, stuffs them in a tuple store, and then when the software that knows what to do with comes along and retrieves it and recognizes the relative URI and can't do much because the base URI is lost. So... IF you know how to handle some particular extension, AND IF you expect to handle it when the extension data has been ripped out of the feed and stored somewhere without any context, THEN you shouldn't use a relative reference. Alternatively, IF you want to empower extensions to process they data they understand, AND IF you want to rip that data out of the feed and store it somewhere, THEN it would be smart to provide software an interface to retrieve context, such as feed-level metadata and the base URI. Sounds like implementor's-guide material to me. And, to whoever said relative references are fragile: Wrong. When you have to move bales of web content around from one place to another, and just supposing hypothetically that you have internal links, relative references are robust, absolute URIs are fragile. - Tim
Re: nested feeds (was: Feed History -02)
Sorry for taking so long to reply. I have been off on a 700km cycle trip http://blogs.sun.com/roller/page/bblfish/20050807 I don't really want to spend to much time on the top-X discussion, as I am a lot more interested in the feed history itself, but here are some thoughts anyway... On 29 Jul 2005, at 17:01, Eric Scheid wrote: On 29/7/05 11:39 PM, Henry Story [EMAIL PROTECTED] wrote: Below I think I have worked out how one can in fact have a top20 feed, and I show how this can be combined without trouble with the history:next ... link... On 29 Jul 2005, at 13:12, Eric Scheid wrote: On 29/7/05 7:57 PM, Henry Story [EMAIL PROTECTED] wrote: 1- The top 20 list: here one wants to move to the previous top 20 list and think of them as one thing. The link to the next feed is not meant to be additive. Each feed is to be seen as a whole. I have a little trouble still thinking of these as feeds, but ... What happens if the publisher realises they have a typo and need to emit an update to an entry? Would the set of 20 entries (with one entry updated) be seen as a complete replacement set? Well if it is a typo and this is considered to be an insignificant change then they can change the typo in the feed document and not need to change any updated time stamps. Misspelling the name of the artist for the top 20 songs list is not insignificant. Even worse fubars are possible too -- such as attributing the wrong artist/author to the #1 song/book (and even worse: leaving off a co-author). Yes, I see this now. This is a problem for my suggestion. The atom:updated field cannot be used to indicate the date at which an entry has a certain position in a chart for the reason you mention. We could then no longer update that entry for spelling mistakes or other more serious issues. One would have to add a about date or something, and then the things gets a little more complicated than I care to think about right now. The way I see it, maybe a better way would be to have a sliding window feed where each entry points to another Atom Feed Document with it's own URI, and it is that second Feed Document which contains the individual items (the top 20 list). This is certainly closer to my intuitions too. A top 20 something is *not* a feed. Feed entries are not ordered, and are not meant to be thought of as a closed collection. At least this is my initial intuition. BUT Not all Atom Feed Documents are feeds, some are static collections of entries. We keep tripping over this :-( I can think of a solution like the following: Let us imagine a top 20 feed where the resources being described by the entries are the position in the top list. So we have entries with ids such as http://TopOfThePops.co.uk/top20/Number1 http://TopOfThePops.co.uk/top20/Number2 http://TopOfThePops.co.uk/top20/Number3 ... will contain a new entry such as entry titleTop of the pops entry number 1/title link href=http://TopOfThePops.co.uk/top20/Number1// idhttp://TopOfThePops.co.uk/top20/Number1/id updated2005-07-05T18:30:00Z/updated summaryTop of the pops winner for the week starting 5 July 2005/summary /entry The problem here is that this doesn't describe the referent, it only describes the reference. I want to see top 20 feeds where each entry links to the referent in question. For example, the Amazon Top 10 Selling Books feed would link to the book specific page at Amazon, not to some page saying the #3 selling book is at the other end of this link. Oh, I don't really want to defend this position too much but there would be a way around this criticism by simply having the link point to the album like this: entry titleTop of the pops entry number 1/title link href=http://www.amazon.fr/exec/obidos/ASIN/B4ULZV/ idhttp://TopOfThePops.co.uk/top20/Number1/id updated2005-07-05T18:30:00Z/updated summaryTop of the pops winner for the week starting 5 July 2005/summary /entry So here the id would be the same for each position from week to week, but the link it points to would change. We would still need to solve the issue of the date at which it had that position, though... And so yes, a feed where the entry is a feed seems easier to work with in this case. The feed would be something like this I suppose: feed titletop 20 French songs/title ... entry titleweek of August 1 2005/title id...?.../id updated2005-08-01T18:30:00Z/updated content src=http://TopOfThePops.fr/top20/2005_08_01/; type=application/atom+xml /entry entry titleweek of August 1 2005/title id...?.../id !--There was an important update-- content src=http://TopOfThePops.fr/top20/2005_08_01/; type=application/atom+xml updated2005-08-02T18:30:00Z/updated /entry entry titleweek of August 8 2005/title id...?.../id
Re: Feed History -02
On 4 Aug 2005, at 06:27, Mark Nottingham wrote: So, if I read you correctly, it sounds like you have a method whereby a 'top20' feed wouldn't need history:prev to give the kind of history that you're thinking of, right? If that's the case, I'm tempted to just tweak the draft so that history:stateful is optional if history:prev is present. I was considering dropping stateful altogether, but I think something is necessary to explicitly say don't try to keep a history of my feed. My latest use case for this is the RSS feed that Netflix provides to let you keep an eye on your queue (sort of like top20, but more specialised). Sound good? Sounds good to me. But I would really like some way to specify that the next feed document is an archive (ie. won't change). This would make it easy for clients to know when to stop following the links, ie, when they have cought up with the changes since they last looked at the feed. Perhaps something like this: history:prev archive=yeshttp://liftoff.msfc.nasa.gov/2003/04/ feed.rss/history Henry Story
Re: Feed History -02
On 9 Aug 2005, at 18:32, Walter Underwood wrote: --On August 9, 2005 9:28:52 AM -0700 James M Snell [EMAIL PROTECTED] wrote: I made some proposals for cache control info (expires and max-age). That might work for this. I missed these proposals. I've been giving some thought to an expires / and max-age / extension myself and was getting ready to write up a draft. Expires is a simple date construct specifying the exact moment (inclusive) that the entry/feed expires. Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the moment specified by atom:updated when then entry/feed expires. The two cannot appear together within a single entry/feed and follows the same basic rules as atom:author elements. Here it is: http://www.intertwingly.net/wiki/pie/PaceCaching Interesting... but why have a limit of one year? For archives, I would like a limit of forever. But otherwise I suppose this would do. Instead of putting the information in the history link of the linking feed, you would put it in the archive feed. Which sounds good. I suppose we end up with some duplication of information here with the http headers again. Adding max-age also means defining IntegerConstruct and disallowing white space around it. Formerly, it was OK as a text construct, but the white space issues change that. Also, we should decide whether cache information is part of the signature. I can see arguments either way. wunder -- Walter Underwood Principal Architect, Verity
Re: Feed History -02
To answer my own question [[ Interesting... but why have a limit of one year? For archives, I would like a limit of forever. ]] I found the following in the HTTP spec [[ To mark a response as never expires, an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. ]] (though that still does not explain why.) Now I am wondering if the http mechanism is perhaps all that is needed for what I want with the unchanging archives. If it is then perhaps this could be explained in the Feed History RFC. Or are there other reasons to add and expires tag to the document itself? Henry Story On 9 Aug 2005, at 19:09, James M Snell wrote: rules as atom:author elements. Here it is: http://www.intertwingly.net/wiki/pie/PaceCaching The expires and max-age elements look fine. I hesitate at bringing in a caching discussion. I'm much more comfortable leaving the definition of caching rules to the protocol level (HTTP) rather than the format extension level. Namely, I don't want to have to go into defining rules for how HTTP headers that affect caching interact with the expires and max-age elements... IMHO, there is simply no value in that. The expires and max-age extension elements affect the feed / entry on the application level not the document level. HTTP caching works on the document level. Adding max-age also means defining IntegerConstruct and disallowing white space around it. Formerly, it was OK as a text construct, but the white space issues change that. This is easy enough. Also, we should decide whether cache information is part of the signature. I can see arguments either way. -1. let's let caching be handled by the transport layer.
Re: Feed History -02
I get the feeling that we should perhaps first list the main types of history archives, and then deal with each one separately. I can see 3: 1- The top 20 list: here one wants to move to the previous top 20 list and think of them as one thing. The link to the next feed is not meant to be additive. Each feed is to be seen as a whole. I have a little trouble still thinking of these as feeds, but ... 2- The history of changes link: the idea here is that a feed is a list of state changes to web resources. The link to the history just increases the length of the feed by pointing to the next feed page. These two pages could have been merged to create one feed page with the same end result. By moving back through the feed history one gets to see the complete history of changes to the resources described by the feed. 3- A listing of the current states of the resources: here the end user is searching for all the blog entries as they currently are. No feed id is ever duplicated across the chain. I think each of these has its uses. 1. this use case is clear and well understood. 2. is very useful for 'static' blog feeds written from a remote server, as once a feed has been archived it no longer needs to be rewritten. It is also very useful in helping a client synchronize with the changes to the feed. If a client is off line for a few months or if there are a lot of changes in a feed then the client just needs to follow this type of link to catch up with all the changes. If the entries are describing state changes to resources such as stock market valuations, then this would allow one to get all the valuations for a company going back in time. 3. It is easier for this to be generated dynamically upon request. It is not really a history of changes, but rather a list of resources. In a feed concerning a blog these two can of course easily be confused as we think of blogs as being created sequentially. We then think of the feed history as the history of the blog entry publication dates. If an old blog entry gets changed then the page on which that blog entry originally appeared in the feed would get changed just as the permalink to the blog post itself gets changed. This type of list is of course not very useful in keeping someone updated as to the changes in a feed, as the whole linked feeds would need to be stepped through to see if anything has changed. I think it is with this version that the proposals of having a separate document that points to all the entries makes most sense. And this case also seems to be worked upon in the API I think. more below... On 23 Jul 2005, at 18:14, Mark Nottingham wrote: On 19/07/2005, at 2:04 AM, Henry Story wrote: Clearly the archive feed will work best if archive documents, once completed (containing a given number of entries) never change. Readers of the archive will have a simple way to know when to stop reading: there should never be a need to re-read an archive page - they just never change. The archive provides a history of the feed's evolution. Earlier changes to the resources described by the feed will be found in older archive documents and newer changes in the later ones. One should expect some entries to be referenced in multiple archive feed documents. These will be entries that have been changed over time. Archives *should not* change. I think any librarian will agree with that. I very much agree that this is the ideal that should be striven for. However, there are some practical problems with doing it in this proposal. First of all, I'm very keen to make it possible to implement history with currently-deployed feed-generating software; e.g., Moveable Type. MT isn't capable of generating a feed where changed entries are repeated at the top out of the box, AFAIK. So is it that MT can only generate feed links such as describe in 3 above? Even if it (and other software) were, it would be very annoying to people whose feed software doesn't understand this extension; their show me the latest entries in the blog feed would become show me the latest changed entries in the blog, and every time an entry was modified or spell-checked, it would show up at the top. Well in many cases this is exactly what I want. If someone makes a big change to a resource that was created one year ago (say your first blog post) then I think this is well worth knowing about. Especially if I have written a comment about it. Of course if the change is not *significant* then the change to the old feed archive would not be significant either. So perhaps I should have said that archives should not change in any *significant* way. So, it's a matter of enabling graceful deployment. Most of the reason I have the fh:stateful flag in there is to allow
Re: Feed History -02
Below I think I have worked out how one can in fact have a top20 feed, and I show how this can be combined without trouble with the history:next ... link... On 29 Jul 2005, at 13:12, Eric Scheid wrote: On 29/7/05 7:57 PM, Henry Story [EMAIL PROTECTED] wrote: 1- The top 20 list: here one wants to move to the previous top 20 list and think of them as one thing. The link to the next feed is not meant to be additive. Each feed is to be seen as a whole. I have a little trouble still thinking of these as feeds, but ... What happens if the publisher realises they have a typo and need to emit an update to an entry? Would the set of 20 entries (with one entry updated) be seen as a complete replacement set? Well if it is a typo and this is considered to be an insignificant change then they can change the typo in the feed document and not need to change any updated time stamps. The way I see it, maybe a better way would be to have a sliding window feed where each entry points to another Atom Feed Document with it's own URI, and it is that second Feed Document which contains the individual items (the top 20 list). This is certainly closer to my intuitions too. A top 20 something is *not* a feed. Feed entries are not ordered, and are not meant to be thought of as a closed collection. At least this is my initial intuition. BUT I can think of a solution like the following: Let us imagine a top 20 feed where the resources being described by the entries are the position in the top list. So we have entries with ids such as http://TopOfThePops.co.uk/top20/Number1 http://TopOfThePops.co.uk/top20/Number2 http://TopOfThePops.co.uk/top20/Number3 ... Each of these resources describes the songs that is at a certain rank in the top of the pops chart. Each week the song in that rank may change. When a change occurs in the song at a certain rank the top 20 feed with id http://TopOfThePops.co.uk/top20/Feed will contain a new entry such as entry titleTop of the pops entry number 1/title link href=http://TopOfThePops.co.uk/top20/Number1// idhttp://TopOfThePops.co.uk/top20/Number1/id updated2005-07-05T18:30:00Z/updated summaryTop of the pops winner for the week starting 5 July 2005/summary /entry A client that would subscribe to such a feed would automatically get updates every week for each of the top 20 resources. But the feed could be structured exactly like I suggest in 2. So for a top 2 feed (20 is a bit to long for me) feed title type=textMy top 2 Software Books/title idhttp://bblfish.net/blog/top2/id history:prevhttp://bblfish.net/blog/top2/ Archive-2005-07-18.atom/history:prev ... entry titleMy Top 1 book/title link href=http://bblfish.net/blog/top2/Number1// idhttp://bblfish.net/blog/top2/Number1/id updated2005-07-25T18:30:00Z/updated summaryMy top 1 book is Service Oriented Computing by Wiley/ summary /entry entry titleMy Top 2 book/title link href=http://bblfish.net/blog/top2/Number2// idhttp://bblfish.net/blog/top2/Number2/id updated2005-07-25T18:30:00Z/updated summaryMy second top book is xml in a Nutshell/summary /entry /feed The above representation of the http://bblfish.net/blog/top2 feed points to the archive feed http://bblfish.net/blog/top2/Archive-2005-07-18.atom feed title type=textMy top 2 Software Books/title idhttp://bblfish.net/blog/top2/id ... entry titleMy Top 1 book/title link href=http://bblfish.net/blog/top2/Number1// idhttp://bblfish.net/blog/top2/Number1/id updated2005-07-18T18:30:00Z/updated summaryMy top 1 book is Java 2D Graphics/summary /entry entry titleMy Top 2 book/title link href=http://bblfish.net/blog/top2/Number2// idhttp://bblfish.net/blog/top2/Number2/id updated2005-07-18T18:30:00Z/updated summaryMy second top book is xml in a Nutshell/summary /entry /feed As you notice only the top1 has changed from the first week but not the second, and yet in both feeds there is an entry for both. A non change can sometimes be an important event. But this is really up to the feed creator to choose how to present his feeds. He could easily have had only had the entry for http://bblfish.net/blog/top2/Number1 in the first feed. Looking at it this way, there really seems to be no incompatibility between a top 20 feed and the history:next ... link. My talk about archives not changing should be more precisely about archives not changing in any significant way. And this advice could be moved to an implementors section and be encoded in HTTP by simply giving archive pages an infinitely long expiry date. Someone could subscribe to that second feed and poll for updates, and all they'll ever see are updates to the 20 items there, not the 20 items from the next week/whatever. The idea of feeds linked to feeds has lots of utility
spam on wiki
The following page has been badly spammed http://www.intertwingly.net/wiki/pie/AtomOWL and it looks like the fact that it was changed never appeared in the RSS feed. Henry
images and logos
I have just published a feed for my blog at http://bblfish.net/blog/ blog.atom I use logo and icon tags. Am I using it correctly? I wanted to add logos and icons to each of the entries too, as each entry at http://bblfish.net/blog/ has an associated image and logo. I guess I will have to create my own extension element and won't be able to reuse the current atom ones. Is anyone else interested in this? Henry
Re: Feed History -02
On 18 Jul 2005, at 23:21, Mark Nottingham wrote: On 18/07/2005, at 2:17 PM, Stefan Eissing wrote: On a more semantic issue: The described sync algorithm will work. In most scenarios the abort condition (e.g. all items on a historical feed are known) will also do the job. However this still means that clients need to check the first fh:prev document if they know all entries there - if my understanding is correct. This is one of the unanswered questions that I left out of scope. The consumer can examine the previous archive's URI and decide as to whether it's seen it or not before, and therefore avoid fetching it if it already has seen it. However, in this approach, it won't see changes that are made in the archive (e.g., if a revision -- even a spelling correction -- is made to an old entry); to do that it either has to walk back the *entire* archive each time, or the feed has to publish all changes -- even to old entries -- at the head of the feed. Clearly the archive feed will work best if archive documents, once completed (containing a given number of entries) never change. Readers of the archive will have a simple way to know when to stop reading: there should never be a need to re-read an archive page - they just never change. The archive provides a history of the feed's evolution. Earlier changes to the resources described by the feed will be found in older archive documents and newer changes in the later ones. One should expect some entries to be referenced in multiple archive feed documents. These will be entries that have been changed over time. Archives *should not* change. I think any librarian will agree with that. I left it out because it has more to do with questions about entry deleting and ordering than with recovering state. it's an arbitrary decision (I had language about this in the original Pace I made), but it seemed like a good trade-off between complexity and capability. Does that make sense, or am I way off-base? Is it worthy to think of something to spare clients and servers this lookup? Are the HTTP caching and If-* header mechanisms good enough to save network bandwidth? An alternate stratgey would be to require that fh:prev documents never change once created. Then a client can terminate the sync once it sees a URI it already knows. And most clients would not do more lookups than they are doing now... I think this would be the correct strategy. Henry Story
Re: Feed History -02
On 19 Jul 2005, at 01:52, A. Pagaltzis wrote: * Mark Nottingham [EMAIL PROTECTED] [2005-07-18 23:30]: This is one of the unanswered questions that I left out of scope. The consumer can examine the previous archive's URI and decide as to whether it's seen it or not before, and therefore avoid fetching it if it already has seen it. However, in this approach, it won't see changes that are made in the archive (e.g., if a revision -- even a spelling correction -- is made to an old entry); to do that it either has to walk back the *entire* archive each time, or the feed has to publish all changes -- even to old entries -- at the head of the feed. These are the kinds of things my “hub archive feed” situation was supposed to address. Because the links are all in one place, the consumer only has to suck down one document in order to be informed of all archive feeds and being able to decide which ones he wants to re-/get. I wonder if what you are trying to describe here is not a different concept altogether from an archive feed. I guess that both are completely orthogonal concepts. Feeds tend to specialize in a number of resources they track. What would also be useful would be a document that described the resources tracked by a feed. This would be closer to a directory listing. It would help point to the current state of the resources tracked by the feed. So when one subscribed to a feed one could then quickly get a list of all the resources that the feed had responsibility for. As this could be quite large some form of navigation may be necessary. Perhaps this is the type of thing that the protocol group is working on. Henry Story Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed History -02
Sorry I did not participate in the previous discussion for format 00. I only just realized this was going on. What is clear is that this is really needed! I agree with Stefan Eissing's random thought that it may not be a good idea to use Atom for a top 10 feed. Atom entries are not ordered in a feed for one. Also as I understand it an entry in a feed is best thought of as a state of an external resource at a time. Making a feed of the top x entries is to use the feed as a closed collection whereas I think it is correctly interpreted as an open one. If that is right, and so fh:stateful is not needed, then would it not be simpler to extend the link element in the following really simple way: link rel=http://purl.org/syndication/history/1.0; type=application/ atom+xml href=http://example.org/2003/11/index.atom; / Just a thought. In any case I really look forward to having this functionality. Thanks a lot for the huge effort you have put into presenting this idea so clearly and with such patience. Henry Story On 18 Jul 2005, at 09:59, Stefan Eissing wrote: Am 16.07.2005 um 17:57 schrieb Mark Nottingham: The Feed History draft has been updated to -02; http://ftp.ietf.org/internet-drafts/draft-nottingham-atompub- feed-history-02.txt The most noticeable change in this version is the inclusion of a namespace URI, to allow implementation. I don't intend to update it for a while, so as to gather implementation feedback. Just a couple of thoughts on reading the document: Ch 3. fh:stateful seems to be only needed for a newborn stateful feed. As an alternative one could drop fh:stateful and define that an empty fh:prev (refering to itself) is the last document in a stateful feed. That would eliminate the cases of wrong mixes of fh:stateful and fh:prev. Ch 5. inserting pseudo-entries into an incomplete feed: would it make sense to have a general way to indicate such pseudo entries? A feed entry can also get lost at the publisher and the publisher might want to indicate that there once was a feed entry, but that he no longer has the (complete) document. //Stefan Random thoughts: The example of a top 10 feed (Ch 1) needs some thinking: there are quite some people interested in the history of top 10 when it comes to music charts. One _could_ make this an atom feed and use the feed history to go back in time. But the underlying model is different from the one atom has, so maybe its not such a good idea after all. (Is there any ordering in a feed, btw.? I know a client can sort by date, but does someone rely on document order of xml elements?)
Re: The Atomic age
It would be easy to add atom to BlogEd, though I really would like the link rel=ext;next href=http://bblfish.net/blog/archive. 10.atom to be agreed upon. This would allow me to place all the blog content in an archive. It would of course also be useful to have the namespace. Henry On 15 Jul 2005, at 17:56, Walter Underwood wrote: --On July 14, 2005 11:37:05 PM -0700 Tim Bray [EMAIL PROTECTED] wrote: So, implementors... to work. Do we have a list of who is implementing it? That could be used in the Deployment section of http://www.tbray.org/atom/RSS-and-Atom. Ultraseek will implement Atom. We need to think more about exactly what it means for a search engine to implement it, but we'll at least spider it. wunder Creature with the Atom Brain, why is he acting so strange? Roky Erickson -- Walter Underwood Principal Architect, Verity
Re: CVS branch merge conflicts
A couple of people pointed me to Eclipse for this, and it does indeed work well for this (thoug the quality of the diffs is not so good as IntelliJs). If it were not so complicated to transform a checked out CVS project into an eclipse project it would be perfect. Henry On 23 Jun 2005, at 12:36, Henry Story wrote: Hi, I am looking for a tool to make it pleasant to resolve merge conflicts between a branch and the HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone know a good tool that one could use for this? Henry Story
Re: CVS branch merge conflicts
Sorry, wrong list. :-/ Henry On 23 Jun 2005, at 18:22, Henry Story wrote: A couple of people pointed me to Eclipse for this, and it does indeed work well for this (thoug the quality of the diffs is not so good as IntelliJs). If it were not so complicated to transform a checked out CVS project into an eclipse project it would be perfect. Henry On 23 Jun 2005, at 12:36, Henry Story wrote: Hi, I am looking for a tool to make it pleasant to resolve merge conflicts between a branch and the HEAD of a cvs repository. This aspect of IntelliJ is broken. Anyone know a good tool that one could use for this? Henry Story
first request for an atom extension: Re: Polling Sucks! (was RE: Atom feed synchronization)
This is a good venue. I think XMPP and polling can be explored. But for the needs of BlogEd [1] on which I am working, and for my personal needs, I would really like us to introduce an extension to the link concept, to provide a pointer to the next page in a historically ordered sequence of feed documents. For many people who have dumb internet connections with very minimal servers, the xmpp solution requires a lot more technology than we have available or want to be bothered with. Something like: link rel=http://.../next; href=http://bblfish.net/blog/archive/ 2005-05-10.atom would be really useful. It requires only a working apache on the server side. On the client side it is really simple to follow. The client just needs to have access to the base feed url, and can follow these links through all the change history of the feed if he wishes. It would allow me to have a: - a remote backup of my blog - provide the means to synchronize it between two editors - allow clients and aggregators to get a complete historical view of the feed. And it comes at really no cost, since all it requires is for us to mint a new next url. So how does one go about extending atom? This was meant to be a feature of it, and especially of the link concept. Henry Story [1] https://bloged.dev.java.net/ [2] http://bblfish.net/blog/ On 18 Jun 2005, at 06:27, James M Snell wrote: Sam asked P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be? I launched this discussion here for three reasons: 1. Everyone who care's about it is probably already here 2. Main discussion about the syntax is pretty much complete so there is no real risk of derailing anything 3. If there was no already accepted solution to the problem, this would be a logical place to begin hunting for and discussing the solution That said, however, is there a better venue that you could suggest? Capping out the conversation a bit, Bob Wyman's RFC3229+feed proposal, once written up into an Internet-Draft, will provide the solution that I'm searching for (e.g. the ability to catch up on what has changed in a feed over a given period of time). The XMPP Push model would likely not be implemented in the case I'm considering but I couldn't rule it out completely. I believe it is Bob's intention to draft up the RFC3229+feed and pitch it to this group for discussion. Sam Ruby wrote: Joe Gregorio wrote: On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote: Joe Gregorio wrote: The one thing missing from the analysis is the overhead, and practicality, of switching protocols (HTTP to XMPP). I'm not aware of anything that might be called overhead. I was referring to switching both the client and server from running HTTP to running XMPP. That may not be practical or even possible for some people. Yes, I understand that you run this right now. Yes, I understand that you run a business doing this right now. Yes, I agree that your solution is one way to solve the problem. Do you agree that 99.99% of all syndication is done via HTTP today and also offering an HTTP based solution would be of value? Joe, I'd be careful with how you structure this argument. It could be applied in a different context, for example: Do you agree that 99.99% of all syndication is done via HTTP GET and POST today and offering a solution based only on these two verbs would be of value? One can go down this path and cater to the least common denominator always, or one can say that perhaps MIDP 1.0 phones are not particularly well adapted to perform complex editing tasks beyond simple GET and POST. Perhaps HTTP is suited to a wide, but not universal, range of applications dealing with relatively coarse and relatively infrequently updated content; and XMPP is well suited to a different -- always on, firehose -- set of applications, with a wide overlap between the two. And perhaps they could be combined. I could see a future where there was a feedmesh backbone with nodes exchanging data via XMPP, serving content out to the rest of the universe via HTTP. - Sam Ruby P.S. Why is this on atom-sytax? Is there a concrete proposal we are talking about here? Is there likely to be?
Re: Atom feed synchronization
The best solution is just to add a link types to the atom syntax: a link to the previous feed document that points to the next bunch of entries. IE. do what web sites do. If you can't find your answer on the first page, go look at the next page. How do you know when to stop? If the pages are ordered chronologically, the client will know to stop when he has come to a page with entries with update times before the date he last looked. This is: - simple, - easy to see (no need to look at invisible header fields), - easy to understand (no need to read another complicated rfc document) - easy to implement (well it so simple) - low tech (you don't need anything more than a server supporting http) Henry On 17 Jun 2005, at 00:37, James M Snell wrote: Ok, question for the group. Scenario: A content source is updated 100 times per hour. The Atom feed currently only displays the 20 most recent entries. Users who are not checking the feed every 10 minutes or so are missing entries. How do we address this? Solution: Rather than using a feed with a fixed number of entries, provide a mechanism that allows users to specify the last time they retrieved the feed and have the feed return all entries added since that time. Question: What is the best way to provide that mechanism: querystring parameter or HTTP header or some other way I'm not thinking of http://...?last-retrieved=12345 OR GET ... HTTP/1.1 Host: ... Last-Retrieved: 12345 - James
Re: Google Sitemaps: Yet another RSS or site-metadata format and Atom competitor
I completely agree. At the core, a feed is just a list of state changes to web resources. It will be the perfect format for notifying search engines of all the changes to a web site, thereby massively reducing the time it will take them to crawl the web. Henry Story On 3 Jun 2005, at 23:28, Bob Wyman wrote: Google has released Sitemaps which is yet-another-format for doing site summary or site-metadata publication. Unlike commonly used RSS formats or Atom, Sitemaps are only intended to communicate information about URLs that have been updated not the content of those URLs.
feeds, ids and categories
I was wondering if I had understood this correctly: a feed can have entries in a number of categories. Each of these categories may themselves have feeds. These category feeds will all have the same id as the main feed, though they may have different titles and subtitles to reflect the category in which they found themselves. Henry
Re: feeds, ids and categories
On 6 Jun 2005, at 16:30, Tim Bray wrote: On Jun 6, 2005, at 6:12 AM, Henry Story wrote: I was wondering if I had understood this correctly: a feed can have entries in a number of categories. Each of these categories may themselves have feeds. These category feeds will all have the same id as the main feed, No! A feed ID is a *unique* identifier. My 'golfing' feed is entirely distinct from my 'chemistry' feed, although they may share some entries. -Tim Phew! Great. Thanks. That is what I was hoping. Because I was going to say that if two category feeds could share the same id and have different titles, then this id would (to stick to our resource/representation distinction introduced in the entry id discussion of Atom entries) simultaneously have two different representations of the same type, and so would have a very different behavior to the ids we have associated with entries. Henry Story
Re: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted
Part of the reason I went into the detailed explanation I did, is because not everyone here may be familiar with mathematical logic. What I was explaining is a heavy condensation of what I learned in my BA in philosophy. I am not plucking these thoughts out of a hat. So let me apply these a little more directly to your proposal. I very much agree with the spirit of what you are saying. But I think that the danger is that by looking at the problem the way you are, we may end up confusing things a lot more than we are clarifying them. On 25 May 2005, at 21:06, Antone Roundy wrote: == Rationale == * The accepted language for allowing duplicate IDs in a feed document speaks only multiple atom:entry elements with the same atom:id describing the same entry if they exist in the same document--of course, we intend for them to describe the same entry whether they're simultaneously in the feed document or not If we put this in terms of ontology, what we want is to state simply that an ID refers to one and only one entry. There is not much to add by the way, other than that the ID is a URI, since the whole role of URIs is to identify one and only one thing. * The accepted language does not speak of the origin feed of the entries. Ideally, an atom:id should be univerally unique to one entry resource, and we rightly require publishers to mint them with that goal. However, in reality, malicious or undereducted publishers might duplicate the IDs of others. Therefore, it is proposed to modify the specification to state that the atom:entry elements describe the same entry (resource) if they originate in the same feed. When you say 'ideally', I say ontologically. Let us imagine that instead of creating an ontology for a atom entry, we were creating one for a gun. We could say that guns have a number of properties, one of them being that they are physical objects. Physical objects can only be at one place at a time. So a gun can only be at one place at a time. Now you can see how it won't help the definition of a gun if someone were to introduce the following reasoning. When a policeman asks someone where they put the gun, some people are honest and tell them where, but many people (the most interesting ones) will lie to them. The policeman has to report the facts as he sees and hears them. He may hear two conflicting reports on where the gun is. Are guns therefore weird objects that have a position relative to the person who speaks about them? This is confusing semantics and the way people speak about the world. It is confusing our concepts about the world, and the context in which sentences containing those concepts about the world appear. * Aggregators wishing to protect against DOS attacks are not unlikely to perform some sort of safety checks to detect malicious atom:id duplication, regardless of whether the specification authorizes them to or not. The policeman is not unlikely to do a lot of safety checks to find out where the gun is. He may for example scan the person who told him he has not gun anyway, just to make sure. On 25 May 2005, at 22:57, Antone Roundy wrote: On Wednesday, May 25, 2005, at 02:26 PM, Henry Story wrote: Since the referents of Superman and Clark Kent are the same, what is true of the one, is true of the other. When speaking directly about the world, we can replace any occurrence of Superman with Clark Kent, and still say something true. Clark Kent is the secret identity of Superman. - Superman is the secret identity of Superman. Whether they're perfectly interchangeable or not depends on whether the name is referring to the object or some a facet of the object. The second sentence actually works if the first Superman refers to the persona, and the second to the person. But getting back to Atom... There are a lot of corner cases. I was trying to give an overview of a complicated field. I was restricting myself to sentences where words clearly identify objects. If you use Superman to refer to a persona then we are speaking about something else. Other cases are Superman is so called because he is strong. Well known, but it does not undermine the distinction I was making. [snip] So to prevent a DOS attack, best is to have aggregator feeds such as: feed !-- aggregator feed -- feed src=http://true.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed feed src=http://false.org; idtag://true.org,2005/feed1/id entry titleEnter your credit card number here/title ... /entry /feed /feed Here all the aggregator feed is claiming is that he has seen entries inside other feeds. ... It will be up to the consumer of such aggregated feeds to decide which to trust. From the end user's point of view, it's not much
