Re: Auto-Discovery and requiring rel="alternate"

On 22/11/04 5:19 AM, "fantasai" <[EMAIL PROTECTED]> wrote: > I did a quick search on the archives here and didn't find any > postings on the matter. I don't believe the auto-discovery spec > should be requiring rel="alternate" on all auto-discovery links > because it is not always the appropriate

Re: PaceFeedState

On 22/11/04 7:41 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > * A "Feed Resource" whose semantic is "I contain the most recent N > entries of this feed." This is the URI that is commonly thought of as > being the Atom feed's URI today; its content changes over time (much as > in the same wa

Re: Auto-Discovery and requiring rel="alternate"

On 22/11/04 6:03 PM, "fantasai" <[EMAIL PROTECTED]> wrote: > Eric Scheid wrote: >> On 22/11/04 5:19 AM, "fantasai" <[EMAIL PROTECTED]> wrote: >> >> For the case of html page --> feed, I too think "alternate" can be a >> mi

updates, and segregating annotations

With talk of intermediaries inserting various extra bits of [whatever] into feeds before passing them on, I've been wondering just how this interplays with updates being re-issued from the original source. If say I publish an atom entry at 1pm, which gets picked up by Foo at 2pm and lards in it's

Re: "Role of RSS in Science Publishing"

On 16/12/04 10:06 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: > In practice it easily allows the addition > of new features in the sense that a human language easily allows new > words - you can have them, as long as you can get everyone to agree > their meaning. Pluggable, but every new plug ne

Re: "Role of RSS in Science Publishing"

On 16/12/04 10:53 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: >> The limit isn't universally true - there are a few languages that support >> algorithmic creation of new words. German, for one IIRC. Turkish too. > > Sure, my apologies. no worries - my point was that while all languages genera

Re: Atom Notification Protocol Published

On 18/12/04 5:42 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > I would strongly recommend that it be required that an atom:entry that is > published with no enclosing atom:feed MUST contain an atom:head element. If > this is not the case, the published atom:entries will be essentially > anonymous

Re: arbitrary limitations in Person

On 4/1/05 8:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote: > - why should a Person only have one associated url? any objections to using atom:link here? (other than generic objections to atom:link, that is) e.

Re: The Atom Format end-game

On 6/1/05 12:26 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > 1. We *must* finalize the format. Our deadline is drawing near and we > need to focus on the publishing protocol. Aside from focusing on the publishing protocol, which is well due, what else happens after we finalise the format spec?

Re: RSS extensibility

On 8/1/05 2:44 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> http://purl.org/atom/ns# >> xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/";> >> >>2005-02-15 >> ... >> >> how about a different example 17 ...

Re: Atom extensibility

On 8/1/05 11:03 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > (This seems so > intuitively obvious that I wouldn't think people would make XML that > didn't work this way, but from the sound of it, there are examples out > there of XML where child elements aren't related to their parents. I

Re: Hash for Links [Was: Re: Posted PaceEnclosuresAndPix]

On 9/1/05 7:28 AM, "Graham" <[EMAIL PROTECTED]> wrote: > I require this functionality in . There is aboslutely > no way I'm initiating 20 HTTP requests (even HEADs) each time the feed > is reloaded. that's what the /feed/entry/modified date is for. e.

Re: Signatures in feeds of Aggregated Entry Documents

On 9/1/05 3:41 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > This would seem to imply that I cannot compose an > Atom Feed Document by collecting together Atom Entry Documents and wrapping > them in a atom:feed - unless I strip out any signatures that might have been > in the Atom Entry Documents

Re: PaceFeedRecursive

On 11/1/05 6:59 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: > Ok, I don't think there is any benefit in the normal case (feed ::= > meta, (meta, content)*), but the recursive nesting method makes it > possible to convey information about relationships between feeds. > Which begs the questions: >

atom entry documents, feed alternates, mime-types

I've realised another use case for atom entry documents. I'm using del.icio.us to track certain memes. For example: http://del.icio.us/tag/atom http://del.icio.us/tag/rss http://del.icio.us/tag/folksonomy For each of those pages they offer an RSS feed. The feed's entries contain the

Re: Questions about -04

On 13/1/05 11:03 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > 2. Why MUST a feed point to an alternate version. What if the feed > is all I publish? I'm -1 on removing this restriction. >>> >>> I'm +1 on removing it, and given the number of people who've >>> commented on it

Re: PaceMustUnderstandElement

-1 I still have misgivings about the underlying model, mainly due to it's binary nature. What happens if at some future point we want to rev the definition of some element which has already been revved once before in it's history? It already has the mU wart, and thus version 3 of that element wou

Re: Feed, know thyself?

On 15/1/05 7:37 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: > If I remember correctly from previous discussions, there is a little > snag with most browsers only passing the data, not the source URI. > Thing is, with the spec as it currently stands, we don't have a link > from the feed that can

Re: Revisiting feed discovery

On 20/1/05 12:40 AM, "Arve Bersvendsen" <[EMAIL PROTECTED]> wrote: > > I have just reread the Atom autodiscovery protocol, at > http://diveintomark.org/rfc/draft-pilgrim-atom-autodiscovery-02.html>. > I have also read http://www.w3.org/Provider/Style/URI>, and I believe > the autodiscovery proto

Re: Revisiting feed discovery

On 20/1/05 2:29 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: >> +1 for "feed", for the link to the resource which is a "sliding window >> representation" of the most recently updated content from which the current >> resource was once published via. Don't use "feed" for links to Atom Feed >> Docu

Re: Revisiting feed discovery

On 20/1/05 3:49 AM, "Arve Bersvendsen" <[EMAIL PROTECTED]> wrote: >>> b) Drop 'type' as a required attribute for link. Make it a 'MAY'. >> >> @type isn't a required attribute. > > In the Atom autodiscovery document I referred to, type is required: mea culpa > 4.2 type attribute > The type

Re: Revisiting feed discovery

On 21/1/05 1:07 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. > > What I have a problem with is «what is the feed for if it isn't an > alternative to the resource you're looking at?». How is a resource which shows the

Re: PaceEntryDeletion status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > If there were no further discussion: The earlier discussion for this > was inconclusive. The demand doesn't seem high enough to get it over > the goal line, but if there is a wave of enthusiasm, there didn't seem > to be that much oppos

Re: PacePersonLinks status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > If there were no further discussion: Has failed to get anywhere near > enough support to call rough consensus in previous go-arounds. -Tim was that failure of consensus due to pushback on the very concept of itself (or related @rel d

Re: Revisiting feed discovery

On 20/1/05 3:46 AM, "Arve Bersvendsen" <[EMAIL PROTECTED]> wrote: >>> a) Change rel="alternate" to rel="feed", rel="subscription" or similar. >> >> On one (technical) level both make sense. However given that the >> current version is pretty widely deployed, a) at least could be >> counter-produ

Re: PaceDateUpdated2 status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > If there were no further discussion: This topic was beaten to death a > few times in the WG. Unless there is a wave of enthusiasm unaccompanied > by -1s, the dates in the current Internet Draft will be all that ships > with the final do

Re: PaceDateofSubject status

On 25/1/05 12:08 PM, "Sascha Carlin" <[EMAIL PROTECTED]> wrote: > Funny enough, I am listed as one of the supporters of this pace. In fact, I am > not: That message of yours talks about "dateline", a similar concept but one which was di

Re: PaceDateUpdated2 status

On 25/1/05 12:33 PM, "Graham" <[EMAIL PROTECTED]> wrote: > BUT, making the updated date optional is something I support. Anyone > else? I originally thought so, but was willing to bend to the will of the developers that didn't like having an element that may or may not be there and thus required

Re: PaceFeedLink status

On 25/1/05 11:17 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > Not yet taken up by the WG, depends on the discussion that comes with > this call. Same rules as all the others: there has to be a positive WG > consensus that each adds to the base specification. -Tim +1 for this pace - the tangible

Re: PacePersonLinks status

On 25/1/05 12:16 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote: > If I understand all the Paces correctly, couldn't you get the same > effect by including foaf as a Structured Extension of Person? only by including the foaf XML right there in the feed (oh the bloat!), or at least sufficient of th

Re: PaceExtensionConstruct status

On 25/1/05 1:10 PM, "David Powell" <[EMAIL PROTECTED]> wrote: > The benefit is that it allows a number of existing vocabularies to be > used with Atom, without them needing rewriting for Atom. example please e.

Re: PaceFeedLink

On 26/1/05 2:16 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote: > I like the proposal in general though I wonder why an absolute URI is > required. One of the intended uses is for when a browser downloads a feed resource to disk, and then hands that file to an atom handler application. Once t

Re: PaceDateofSubject status

On 26/1/05 12:24 AM, "Sascha Carlin" <[EMAIL PROTECTED]> wrote: > Eric Scheid wrote: >> That message of yours talks about "dateline", a similar concept but one >> which was discussed quite some time before DateOfSubject was proposed (July, >&g

Re: PaceMustBeWellFormed status

On 26/1/05 8:58 AM, "Walter Underwood" <[EMAIL PROTECTED]> wrote: > An external transport protocol (e.g. HTTP with text/xml content-type) > may force the document to be decoded as US-ASCII. In that case ... +1 e.

Re: PaceFeedLink

On 26/1/05 4:44 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> Agreed. Then the only comment that remains is: >> >> # Also, could an additional requirement be added. Namely that >> # aggregators use the URI in |rel="self"| to check for the feed next >> # time? > > -1 > > If I got the feed from l

Re: PaceFeedLink

On 26/1/05 11:50 AM, "Martin Duerst" <[EMAIL PROTECTED]> wrote: >> A relative URI would only be useful if there is in fact an xml:base in >> effect. With no xml:base then the relative reference would be useless. > > That's pretty obvious, and applies to all other links. If we want to > point tha

Re: PaceEnclosuresAndPix status

On 26/1/05 3:59 AM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> -0.7. Turns into a kitchen sink by using it to point to things >> that are intended to be pre-fetched and presented along with the content > > I agree. I think we should have chosen another element name. turns > out to be HTM

Re: Issues with draft-ietf-atompub-format-04

On 26/1/05 2:49 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> [3.1.1 says TYPE is one thing] >> [3.5.2 says TYPE is the opposite] > Ah, you're right. Still don't see how it's vague, though. It's only clear what's going on when the reader juxtaposes the two sections, and realises that the con

Re: Revisiting feed discovery

On 26/1/05 5:02 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> How is a resource which shows the last 15 entries as of today an >> "alternative" representation of an entry which was published six months >> ago and has long slipped out of the sliding window? > > It isn't, and that's not what

Re: PaceFeedLink

On 27/1/05 7:47 AM, "Sjoerd Visscher" <[EMAIL PROTECTED]> wrote: > The whole point of xml:base is that an application that stores a page > outside of its original context can add an xml:base to prevent losing > the original location context. browsers don't. all they know is here is a URL to a r

Re: Difference of TEXT and XHTML?

On 27/1/05 9:24 AM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: > Sorry, I don't understand what your example is demonstrating. > > How would the above be different from: > type='XHTML'>I do not like < > marquee> > Ido not like ... try instead this example

Re: PaceEnclosuresAndPix status

On 27/1/05 2:25 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > For quite some time, my XHTML has contained the following: > > > > Question: would it be of value to people like Graham and Brent if we > were to "register" this rel value for Atom feeds? that's not "a" value. that's two @rel values

Re: PaceEnclosuresAndPix status

On 27/1/05 3:01 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> For quite some time, my XHTML has contained the following: >> >> >> >> Question: would it be of value to people like Graham and Brent if we >> were to "register" this rel value for Atom feeds? > > Heh, didn't know that. Much bett

Re: PaceEnclosuresAndPix status

On 27/1/05 3:38 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: >> atom:@rel doesn't allow for multiple space delimited values. >> >> e. > > http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html agreed, a single term @rel value is preferred. the "shortcut icon" thing is borked ... the link

Re: Difference of TEXT and XHTML?

On 27/1/05 6:14 PM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: >> try instead this example "I <3 Huckabees"... > > That makes no difference, either. > > I <3 Huckabees > > Only type='HTML' is different. >

Re: Difference of TEXT and XHTML?

On 27/1/05 6:23 PM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: > But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' > with only text content). What value does type='TEXT' add to the format > except the ability of feedvalidator.org to detect cases where there are > element chi

Re: PaceEnclosuresAndPix status

On 27/1/05 7:26 PM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or I've drafted a Pace for this... http://www.intertwingly.net/wiki/pie/PaceIconAn

Re: Difference of TEXT and XHTML?

On 27/1/05 11:22 PM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: > When Huckabees". To form an XHTML document, you don't concatenate that > string to some source markup, but you move the text node to a tree like > this (assume XHTML namespace): > html > head > body >div > #text: "I <3

PaceIconAndImage, and PaceLinkEnclosure

resending with more appropriate subject line, just in case these two new paces got lost in the thread... > I'd prefer an element, because the nature of the favicon reference is > not that a user would want to manually follow the link. That is: > > or I've drafted a Pace for this... http

Re: PaceIconAndImage

On 28/1/05 4:03 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: >> Also, why limit this to feed/head, and not entry? So that Atom >> feeds will be easily convertible to RSS 2.0? > > Converting *to* RSS 2.0 shouldn't be a goal or even a consideration > in any Atom related discussions. Only conversion

Re: PaceIconAndImage

On 28/1/05 3:08 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > Also, why limit this to feed/head, and not entry? So that Atom feeds > will be easily convertible to RSS 2.0? Certainly there are ways to add > images to entries in RSS 2.0, though not icons (as far as I'm aware), > but I don't th

Re: Multiple content allowed?

On 28/1/05 4:03 AM, "Norman Walsh" <[EMAIL PROTECTED]> wrote: > Someone sent me this, noting that it was not valid according to the > grammar I posted. He thought it was legal according to the spec, > and I'm not sure. What say you? not legal. 5.12 "atom:content" Element The "atom:cont

Re: Mandatory method of specifying XHTML namespace?

On 28/1/05 7:39 AM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: >> If the value of "type" is "XHTML", the content of the Text construct >> MUST be a single xhtml:div element > > -1 gratuitous element cruft. The text construct element itself serves > as a container. but atom:title != xhtml:title

Re: PaceIconAndImage

On 28/1/05 10:02 AM, "Eric Scheid" <[EMAIL PROTECTED]> wrote: > I used a Link construct to keep word count down and now with -05 published there is no generic Link Construct. I'll update the pace with all the necessary extra wordage and bloat. e.

Re: Mandatory method of specifying XHTML namespace?

On 28/1/05 4:58 PM, "Henri Sivonen" <[EMAIL PROTECTED]> wrote: > Copyright 2005 John Doe, all rights > reserved > (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML > namespace) is less crufty than > xmlns='http://www.w3.org/1999/xhtml'>Copyright 2005 John Doe, all > rights res

Re: PaceEnclosuresAndPix status

On 29/1/05 4:22 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: >> http://www.intertwingly.net/wiki/pie/PaceIconAndImage > > Nice. But if we have both atom:icon and atom:image for the feed, why do we > need to do all kinds of wierd stuff to have images attached to Atom > entries? Can't atom

how to write spec language for language variants?

nitpickers welcome. I have this spec text in my draft Pace... > atom:head elements MAY contain one or more atom:foo elements, so > long no two atom:foo elements have the same combination of > atom:hreflang, xml:lang, or atom:type. I also considered writing it like this... > atom:head e

Re: PaceEnclosuresAndPix status

On 29/1/05 5:15 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote: > I know what we're talking about and still don't understand why embedding > so-called «favorite icons» is so wildely different from embedding other > types of graphical objects in feeds (at all levels) that it has to be done > in a

Re: Comments on format-05

On 30/1/05 6:48 PM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > * 3.1 Text Constructs -- Since the atom:content no longer references > this construct, my preference would be to remove this section > altogether and make atom:title, atom:copyright, atom:summary, > atom:tagline and atom:info have

Re: Comments on format-05

On 31/1/05 3:47 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> +1, but not just type attributes, also xml:lang variations please. > > -1. An Atom entry is *one* representation and you can link to alternates. > I'm deeply unhappy that this was raised again. We went over and over on > the matter

atom:contributor cardinality in -05

> atom:head elements MUST NOT contain more than one atom:contributor element. > atom:entry elements MUST NOT contain more than one atom:contributor element. they look like a copy/pasto, especially since above those lines there is > & atomContributor* e.

Re: PaceXhtmlNamespaceDiv posted

On 31/1/05 4:43 AM, "Julian Reschke" <[EMAIL PROTECTED]> wrote: > "The content SHOULD be XHTML text and markup that could validly appear > directly within an xhtml:div element." > > ...so making it explicit in the on-the-wire format seems to be > completely useless. what's missing though is gui

Re: URI canonicalization

On 31/1/05 6:17 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> "Instances of Identity constructs can be compared to determine whether >> an entry or feed is the same as one seen before. Processors MUST >> compare Identity constructs on a character-by-character basis in a >> case-sensitive fashi

Re: URI canonicalization

On 31/1/05 10:16 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > I agree with you in principle, but I find the current text unrealistic. > It's just fodder for stupid arguments. what? and "Atom Processors MAY perform additional scheme-specific comparisions" won't lead to stupid arguments? Here's

Re: Dereferencing Identity Constructs

On 31/1/05 3:22 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > "When using to ascertain whether two Atom entries or feeds > are the same, such operations MUST be based only on the URI character > strings, and MUST NOT rely on dereferencing the URIs." +1

Re: Comments on format-05

On 1/2/05 6:02 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > If the concern about multiple content is solely that it will result in > more bandwidth use, I think it's misplaced; people who are concerned > about bandwidth won't publish multiple representations inline; forcing > them not to by

Re: Comments on format-05

On 1/2/05 5:31 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > Another option would be to allow one with inline content, and > alternative content by reference, eg. (not being careful about getting > language tags correct): +1

Re: Feed State [was: Work Queue Rotation #16]

On 1/2/05 4:18 PM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > P.S. Feed Document may be somewhat misleading, because it's easy to > confuse it with Feed (which has connotations of the information > channel). I think "Feed Snapshot Document" or the like was once > proposed, but it was shot dow

Re: URI canonicalization

On 2/2/05 10:03 AM, "Graham" <[EMAIL PROTECTED]> wrote: > Aren't we approaching this problem from the wrong end? The id spec > should be instructions for publishers saying "Any two versions of the > same entry must use the same id, which requires that all characters are > the same. Any two differ

Re: URI canonicalization

On 2/2/05 11:52 AM, "Roy T. Fielding" <[EMAIL PROTECTED]> wrote: > any two > URIs that are different identifiers will never compare as > "equivalent", regardless of the comparison algorithm used. what about false negatives though? e.

Re: Revised PaceIconAndImage, added PaceMultipleImages

On 2/2/05 5:49 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > Having produced my own Atom feed has made me a supporter of this Pace; > without getting too deep into it while However, this Pace needed work; first of all, it was based on link > constructs, which no longer exist. So I revised it. I

Re: Trial format-05 atom feed

On 2/2/05 11:29 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: >> http://www.tbray.org/ongoing/ongoing.atom > > the xmlns and version indicate format-04. -05 is functionally equivalent to -04 (sans errors) e.

Re: Call for final Paces for consideration: deadline imminent

On 3/2/05 3:36 PM, "Walter Underwood" <[EMAIL PROTECTED]> wrote: > Is the current Atom spec sufficient for archiving? If not, we aren't done. We might need a new @rel value or two. Entries can be published in feeds which are then no longer updated. the spec supports this as is. what we don't ha

Re: Call for final Paces for consideration: deadline imminent

On 3/2/05 4:01 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: > 4.) Atom sucks at blogs with comments or trackbacks > 5.) Atom sucks at anything with a representation of its own and >collection membership e.

PaceCollection

http://intertwingly.net/wiki/pie/PaceCollection == Abstract == Rename the top level element name for the atom document format which holds a collection of entries, to better communicate it's "collection" nature, and more easily allow non-"feed" collections. == Status == Open == Related and Co

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

On 3/2/05 5:09 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > What is the model for archiving with Atom? One or more distinct Atom > feeds that each contain a collection of old entries? If so, what we > need then is a just container for feeds. One that encapsulates by > reference rather than by

Re: PaceCollection

On 3/2/05 5:12 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > -1. A name change of the top level element accomplishes nothing. It eliminates confusion when people talk of "an atom feed". The unpleasant reality is that Atom will succeed in the real world depending on how well people understand wh

Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)

On 3/2/05 5:46 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > Well, from your Pace: "Atom Feed Documents are properly collections, > of which "feeds" are just one semantic. Other semantics for Atom > Collection Documents include "archives", "directory", "comments", > "trackbacks", "pings", "parts

Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent)

On 3/2/05 7:18 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> This is better. I guess I just hadn't grok'd the idea of using >> entries to reference feeds, but now that I see the angle brackets I >> get it. > > Yes, feeds are entries. no, feeds are collections, entries describe resources, an

Re: ServiceElement and other matters

On 3/2/05 6:50 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > 2. Entry id's. Ok, so they are supposed to be "universally unique". > That's all good and fine. But what if... hypothetically... my Atom > reader gets two copies of the same Entry with different metadata. > They are the same entry be

Re: PaceCollection

On 4/2/05 4:49 AM, "James Snell" <[EMAIL PROTECTED]> wrote: > You wouldn't need to change them if "guacamole" had a well-known, > well-understood meaning in relation to what the XML syntax was trying > to accomplish. The term "feed" has a well-known, well-understood > meaning. Fruit & veg depart

Re: Organization Use Cases

On 4/2/05 1:54 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> I believe there is a proposal for a which would do >> the job. > > It wouldn't handle that example. The comments are nested. XML elements > nest pretty well. It would handle the first case... but only by > reference. You couldn't "

Re: PaceAggregationDocument (was: On organization and abstraction)

On 4/2/05 2:06 PM, "Graham" <[EMAIL PROTECTED]> wrote: > If you removed the ability to have entries within the feeds in > aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally > different task. > > A collection of feeds would be something like a list of blogs about a > certain to

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

On 4/2/05 1:15 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: >> 3.) A "List Status" feed, where the only updates consist of one >> collection replacing another. >> >> RSS2 -- >> http://rss.netflix.com/Top100RSS >> >> background info-- >> http://www.25hoursaday.com/weblog/PermaLink.a

Re: New Pace: PaceAggregationInSeparateSpec

On 4/2/05 5:07 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > Defer the definition of solutions for aggregated feeds to a separate > Internet-Draft that is not a part of the Atom core syntax > specification. +1

Re: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...)

>> Because CAP is an XML format, we're using atom:content elements with >> type="text/xml". In order to ensure that there is something for aggregators >> to display if they don't understand CAP, we're generating atom:summary >> elements that contain a textual summary of the CAP message which is i

Re: Feed State [was: Work Queue Rotation #16]

On 4/2/05 4:03 PM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote: > This is now PaceNoFeedState; > http://www.intertwingly.net/wiki/pie/PaceNoFeedState +1 e.

Re: New Pace: PaceAggregationInSeparateSpec

On 4/2/05 6:14 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> leaving things as they are >> and deferring deciding how to handle aggregation would irreversibly >> enshrine HeadInEntry into the format, which all of the current >> organizational proposals are trying to replace. > > That's right.

Re: New Pace: PaceAggregationInSeparateSpec

On 4/2/05 6:48 PM, "James Snell" <[EMAIL PROTECTED]> wrote: > I agree with this so long as there is a core mechanism that allows a > standalone entry to identify the feed to which it belongs. That > mechanism does not have to be atom:head, but it does need to be part > of the core. hmmm ... i

Re: PaceRemoveVersionAttr

I just had a thought (astounding!) If we remove the version attribute and change the namespace only when there is a backwards incompatible spec revision, and assume mustIgnore for unrecognised elements from any minor version updates ... then this leaves the door open for someone to produce feeds

Re: Posted PaceEntryOrder (was Entry order)

On 5/2/05 12:14 PM, "Graham" <[EMAIL PROTECTED]> wrote: >> {{{ This specification assigns no significance to the order of >> atom:entry elements within the feed. Processors MAY present entries in >> a different order to which they are appear in an Atom Feed Document. >> }}} > > First sentence no

Re: Call for final Paces for consideration: deadline imminent

On 6/2/05 4:27 AM, "David Powell" <[EMAIL PROTECTED]> wrote: > Although we could keep the model we have (let's call it the 'mutable entries' > model), it isn’t clear on a number of issues. Eg, if an old version of an > entry has some property that isn’t present in a newer version, does that >

Re: PaceRepeatIdInDocument posted

On 6/2/05 8:41 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > If > anything we should address the lack of a standard method for creating > atom:id's and we should create a requirement that atom:updated must be > changed on *every* update -- not just on the whim of the entry author... arrgh! atom:

Re: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339)

On 6/2/05 9:38 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > I am +1 on the regular expression limitation, > believe that all dates that that conform to this limitation are valid > RFC 3339 and xsd:dateTime values, and believe that it will interop with > all of the existing XSD implementations. wh

Re: PaceClarifyDateUpdated

On 6/2/05 10:48 AM, "Graham" <[EMAIL PROTECTED]> wrote: > Therefore, other modifications SHOULD NOT result in a changed > atom:updated value. +1 e.

Re: PaceRepeatIdInDocument posted

On 6/2/05 9:55 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > I would prefer a solution whereby if somebody wants to include versions > of entries into a feed they need to include a version specific > identifier. +1. e.

Re: New: PaceProfileAttribute

On 6/2/05 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote: > atom:feed and atom:entry elements MAY have a "profile" attribute whose > value is a list of names or URI's identifying one or more metadata > profiles that have been applied to the feed or entry. A profile is a > description what m

dereferencability of ?

consider assume for the moment that is a valid scheme is that kind of URI something we want to allow in link/@href? putting it another way, look closely at this example [...] http://example.com/892379587493 http://example.com/2005/02/mut

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

On 7/2/05 6:20 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > In this particular debate, the core issue is "What is a Feed > Document?" I have long contended that a Feed Document is a "sliding window" > on a feed. Sayre and others have said that a Feed Document is "a > representation of the current

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

On 7/2/05 8:58 AM, "John Panzer" <[EMAIL PROTECTED]> wrote: > Since an entry is identified uniquely by its atom:id (though it can have > different states at different times); And, since it's not possible to add more > than one of any unique thing to a (mathematical) set; And, since Sliding > Wind

  1   2   3   4   5   >