On 18/10/05 4:39 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
>
> Eric Scheid wrote:
>
>> Ask yourself these questions: which is the "first" message in this thread,
>> and if you wanted to understand the thread would you start there, or at t
On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> 2) Search results, where the order of everything all along the entire
> chain shifts around all the time.
>
> BTW, case 2 destroys the idea of a "fixed" end and a "live" end.
Case 2 would be a closed set, generally speaking.
Te
On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> Can "self" be polymorphic--the subscription URI in the live end of a
> feed, and "this chunk" in a historical chunk? Can an extension speak
> authoritatively about the meaning of something from the core spec?
If it were so, and y
On 18/10/05 2:04 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
>> I'd prefer that our use of 'prev' and 'next' be consistent with other uses
>> elsewhere, where 'next' traverses from the current position to the one that
>> *follows*, whether in time or logical order. Consider the use of
>> 'fi
On 18/10/05 12:43 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> Eric Scheid wrote:
>
>> I'd prefer that our use of 'prev' and 'next' be consistent with other uses
>> elsewhere, where 'next' traverses from the current po
On 17/10/05 9:30 PM, "Lindsley Brett-ABL001" <[EMAIL PROTECTED]>
wrote:
> I would like to toss out another thought - since the updated time of a
> feed is required, maybe it can be used to help determine the feed
> order/history.
> For example, if following a "next" link (or pick your favorite t
On 17/10/05 5:09 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> 1. Which relationship, next or prev, is used to specify a link backwards in
> time to an older archive. Mark Nottingham's Feed History proposal used prev.
> Mark Pilgrim's XML.com article used next.
I'd prefer that our use of
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 use
On 15/10/05 1:32 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> My answer would be: if "last" is used, it's a closed set; if "last" is
> not used, it's an open set.
+1 ... if it's an open set and you've put 'last' links into every archive,
then every time you extend the set you have to rewrite
On 15/10/05 8:28 AM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> Is the 'first' the feed document that changes, whereas 'next' and 'last'
> point to the archives? (in a feed history context?)
My thinking is that of the two ends, 'first' and 'last', it would normally
be the 'first' end that is anc
On 15/10/05 12:48 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
> Also -- I'd think that the "last" link is already covered by "self,"
> no? If not, there's some pretty serious confusion about what 'self'
> means.
What if a magazine publishes articles only once per month, each month's
entries
On 14/10/05 2:01 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
> Eric,
> It's like deja-vu all over again.
>
> http://bitworking.org/news/Atom_Auto_Sub_How_To
>
> :)
I'd forgotten about that, I was only remembering the wiki.
I still think it odd that one could traverse both "prev" and "next
On 14/10/05 9:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Excellent. If this works out, there is an opportunity to merge the
> paging behavior of Feed History, OpenSearch and APP collections into a
> single set of paging link relations (next/previous/first/last).
'first' or 'start'?
Do
On 12/10/05 7:54 PM, "Pascal Philippe" <[EMAIL PROTECTED]> wrote:
> I would like to try to understand why we can't have more than one
> atom:content element within an atom:entry element. Could you give me
> the reason of this choice?
IIRC, it was thought it would be too burdensome for developers
On 10/10/05 2:02 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>> * dcterms:valid has slightly more functionality in that you get to
>> specify a start date.
>>
> I don't necessarily want more functionality. The atom:updated date
> gives us a perfectly good start date.
Perhaps atom:published
On 2/10/05 3:54 PM, "James M Snell" <[EMAIL PROTECTED]> 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 mult
On 21/9/05 9:35 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> Marking entries as having no rank sounds like a nice idea, but I don't think
> it's feasible in the long run.
thinking more ... I think the way to handle this is that the client
application could weight the ranking with the age
On 21/9/05 1:05 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> The ranking is part of the entry metadata. If an entry falls off the
> feed, there is no effect on the ranking metadata. With partial feed
> retrieval, ordering could be performed over the entire set of entries.
How does this hel
On 21/9/05 5:18 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> For instance
>
>
> ...
> 10
>
>
> ...
> 5
>
>
What happens when entries "fall off the bottom" ... do their rankings
expire? How does that work with the diff+Feed method of partial feed
retrieval?
e.
Tis be gettin' t' th' time o' year when pirates be stalking th' deck. Arrr!
(I can't keep that up...)
there's a serious point ... I've just had the dubious pleasure of seeing a
couple of subscriptions have all their entries marked as changed/unread, and
on inspection I see they've flipped the ma
On 15/9/05 6:06 AM, "David Powell" <[EMAIL PROTECTED]> wrote:
> Eg - An Atom library or server that doesn't know about this extension
> is free to not preserve the entry order, and yet to retain the
> element, even though this will have corrupted the data.
very good point.
e.
On 12/9/05 9:00 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * Henry Story <[EMAIL PROTECTED]> [2005-09-12 00:05]:
>> 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 tex
On 7/9/05 11:09 PM, "Roland Jungwirth" <[EMAIL PROTECTED]> wrote:
> When going through the Atom specification regarding syntax
> (http://ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt), I
> came to point 4.1.1 "The atom:feed Element". This states that every
> atom:feed element has to h
On 31/8/05 7:50 AM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote:
> Is not logical order, if any, determined by the datetime of the
> published (or updated) element?
No. I've seen a few things online where they publish chapter 3 first,
followed by chapter 8, and then go back and fill in the bla
On 31/8/05 6:01 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
> It sounds like you've got use cases for Atom that other use cases
> (e.g., lists) make difficult to work with. Banning those other use
> cases makes things easier for you, but I don't think it's good for
> Atom overall.
those oth
On 30/8/05 12:05 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> That's kinda where I was going with x:follow="no|yes". An
> x:archive="no|yes" would also make some sense but could also be handled
> with HTTP caching (e.g. set the referenced content to expire
> immediately). x:index="no|yes" d
On 30/8/05 11:19 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> http://www.example.com/enclosure.mp3";
> x:follow="no" />
> http://www.example.com/enclosure.mp3";
> x:follow="yes" />
>
> http://www.example.com/enclosure.mp3"; x:follow="no" />
> http://www.example.com/enclosure.mp3"; x:follow="
On 27/8/05 6:40 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> I think "crawling" URI's found in tags,
> tags and enclosures isn't crawling... Or... Is there something I'm
> missing here?
crawling tags isn't a huge problem because it doesn't lead to a
recursive situation. Same withh stylesheets
On 26/8/05 3:55 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> Remember, PubSub never does
> anything that a desktop client doesn't do.
Periodic re-fetching is a robotic behaviour, common to both desktop
aggregators and server based aggregators. Robots.txt was established to
minimise harm caused b
On 22/8/05 1:45 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote:
>>
>> location#1
>
> #2 through #4 seem understandable, but what the heck is #1?
> [a] "The place where this feed was put together"?
> [b] "The place where this feed was originally grabbed from"?
[a] would suffer the AOL problem,
On 24/8/05 1:02 PM, "Karl Dubost" <[EMAIL PROTECTED]> wrote:
>>
>>
>> foo
>> location#2
>>
>
> What is location#2?
>a. The usual location of the author as in the place is living
> right now?
>b. The place of his origins?
>c. The place where he's blogging right now?
>
On 22/8/05 10:28 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> What should an aggregate feed generator like PubSub do when it finds
> an entry in a feed that contains unscoped extensions as children of the
> feed?
It's an interesting problem. A pity now that the idea of segregating
entry-default
On 22/8/05 9:22 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> The crux of the question is: what happens when an extension that does
>> not specify the scope appears at the feed level?
>
> I'm not sure why this question is interesting. What sort of
> application would need to know?
a search e
In this example, can anything intelligent be said about the various
different locations? Is my intent clear, or are there clear ambiguities?
...
location#1
foo
location#2
foo
location#3
location#4
...
...
e.
On 12/8/05 2:29 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> Note that there MUST be no whitespace in a Date construct or in
>> any IRI. Some XML-emitting implementations erroneously insert
>> whitespace around values by default, and such implementations
>> will emit invalid Atom.
>
> +1
>
On 11/8/05 3:20 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers
> to the source as well, that base is covered anyway.
I'd prefer to see atom:[EMAIL PROTECTED]"in-reply-to"].
Of course it's "related". All links in an entry p
On 11/8/05 3:05 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> What scenario exists wherein it would be *more* desirable to
> provide *only* a dereferencable location but *not* an ID? When
> would it be *wiser* to *rely* on a pointer to a resource which is
> always in danger of voiding, irrecove
On 10/8/05 12:46 PM, "James M Snell" <[EMAIL PROTECTED]> 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
>
Looks good, I think it does need a little bit of prose ex
On 5/8/05 7:48 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> > href="http://www.example.com/atom";
>> type="application/atom+xml"
>> thread:idref="urn:foo:1" />
>>
>> this way processors that have a basic understanding of what a
>> is can still do something
On 5/8/05 9:55 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> Uh, consider
>
> href="http://example.org/evil"; />
>
> What useful thing is there that software could sanely do, knowing
> only that something is a link? -Tim
>
not knowing what that particular @rel actually means, it could sti
On 5/8/05 3:07 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> src="http://www.example.com/atom"; />
how about this instead
http://www.example.com/atom";
type="application/atom+xml"
thread:idref="urn:foo:1" />
this way processors that have a basic understanding of wha
On 5/8/05 1:30 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 04:55]:
>> What if those particular had @rel="in-reply-to", and
>> per that spec would be the URIs. Would updating those URIs
&
A question...
If I have a store of entries, which of course contain many s, and at
some point I retrieve various of those links and find that some of them
respond with 301 Moved and a new Location ... should I then be updating the
s in my store? What if those particular had
@rel="in-reply-to", a
On 2/8/05 12:38 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> http://www.atomenabled.org/developers/syndication/
>
> Feedback welcome.
" is patterned after html's link element. "
[...]
"rel indicates the link relationship type. "
It would be good to indicate that atom:rel is different from html'
On 1/8/05 5:39 PM, "David Powell" <[EMAIL PROTECTED]> wrote:
>
>> This specification does not place any restrictions on what elements
>> may be used as Metadata Extensions, but the RelaxNG grammar
>> explicitly excludes elements in the Atom namespace. The Atom
>> namespace is reserved for future
On 1/8/05 9:34 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> If anyone objects to any of the *new
> text*, please speak up.
spello:
s/forwards-compatable/forwards-compatible/
e.
On 31/7/05 7:47 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I¹m -1 on using ³replies-source²; I should have said so more
> explicitly before. To me it is non-sensical, as it parses as ³the
> source of replies,² which is the opposite relationship of what
> it¹s supposed to express. It¹s not wh
On 31/7/05 8:16 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
>
>
>
>
> ...unless it were done this way:
>
>
>
>
Why not this...
While true that nesting elements does allow for more flexible cardinality,
in practice will that actually hap
On 31/7/05 7:47 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I¹m -1 on using ³replies-source²; I should have said so more
> explicitly before. To me it is non-sensical, as it parses as ³the
> source of replies,² which is the opposite relationship of what
> it¹s supposed to express. It¹s not wh
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
> link...
>
>
> On 29 Jul 2005, at 13:12, Eric Scheid wrote
On 29/7/05 9:12 PM, "Eric Scheid" <[EMAIL PROTECTED]> wrote:
> It's conceivable they could also provide a feed for each publication
> pointing to the table of contents feeds of each issue. That is, a feed with
> an entry for each issue.
There is another issue with
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
> thi
On 29/7/05 2:45 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> For the comments extension, I can write the Internet Draft such that the
> link rels are registered with IANA or are identified by fully qualified
> URI's. What is the general preference of the group? I'd prefer IANA
> registration
On 26/7/05 7:53 AM, "Blaine Garrett" <[EMAIL PROTECTED]> wrote:
> From my searching, in the name of simplicity, RSS and ATOM reject the idea of
> nested channels/feeds.
Not at all in the case of Atom. An entry can contain one or more
elements, and these link elements would point to various reso
On 20/7/05 3:08 PM, "James Cerra" <[EMAIL PROTECTED]> wrote:
> Section 3.2.2:
> --
>> The "atom:uri" element's content conveys an IRI associated with the person.
>> Person constructs MAY contain an atom:uri element, but MUST NOT contain more
>> than one. The content of atom:uri in a
On 17/7/05 2:27 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>> It would make more sense to me to say that a particular type of
>> @rel value always expects a dereferencable URI or never expects
>> on. ³in-reply-to² would be in the latter category.
>>
>>
>>
> +1. Atom 1.0 does not require
On 13/7/05 5:17 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I should clarify that I defer this to the particular relationship
> type. In an atom:[EMAIL PROTECTED]'alternate'], I do absolutely expect
> the @href to be dereferencable. What I don¹t see any reason for
> is to mandate that @href m
On 13/7/05 4:25 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> True, but this doesn¹t detract from my argument that we need to
> be able to signify a tighter relationship than just ³related.² An
> aggregator might want to offer different UI for comment feeds, in
> contrast to merely ³related² fe
On 1/7/05 7:01 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> Atom Processors that sign Atom Documents MUST support the use
> of Canonical XML.
what about Atom Processors that are not signing stuff, but is instead
reading/validating those signatures?
e.
On 30/6/05 11:54 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> I don't quite get what the "hub feed" would look like. Could you show
> us some XML?
I think something like this:
...
archives hub for x
http://example.com/archive/feed/2005/05/";
type="application/atom+xm
On 30/6/05 11:54 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
>> I¹d much rather have a single archive feed containing all
>> entries, and use RFC3229+feed to return partial versions of it;
> That might be good for those who can support it, but many people won't
> be able to. On the other hand
On 24/6/05 1:28 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
>> In other words, this isn't bad news, just a delay.
>
> Fully disagree. The world has many implementors eagerly awaiting the
> arrival of Atom so they can start using it. If there are problems
> that require repair, I don't want to wa
On 22/6/05 1:39 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote:
>> One would also have to contend with the potential problems
>> introduced by namespace declarations with the feed. The bottom line
>> of this is that an entry with a signature could not simply be copied
>> over to a new containing
On 18/6/05 7:42 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> So what if I provide a "src" attribute but no "type" attribute?
> The "type" attribute would "default" to "text", but "text" is forbidden
> if "src" is provided...
>
> I suggest that if src is provided but not type, there is no "ty
On 18/6/05 6:57 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> Let's keep Atom as it is now -- without the "first" and "next" tags
> and encourage folk who need to keep up with high volume streams to use Atom
> over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
> good thin
On 18/6/05 3:14 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
>
> Uh, has Mark spotted a dumb bug here that we should fix? Do we care
> if *remote* content is of a composite MIME type? My feeling was that
> we ruled out composite types in *local* content, for fairly obvious
> reasons. The fix is
On 17/6/05 10:25 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>> Something involving eTags would be the simplest from the client end.
>>
>>
> Agreed, but it seems to be a bit of a trick to figure out what that
> "something involvig eTags" could be ;-)
>
> None of the existing HTTP Headers th
On 17/6/05 8:37 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Question: What is the best way to provide that mechanism: querystring
> parameter or HTTP header or some other way I'm not thinking of
Something involving eTags would be the simplest from the client end.
e.
On 6/6/05 11:12 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> These category feeds will all have the same id
> as the main feed
maybe not.
would every feed at nature.com have the same id?
e.
On 4/6/05 10:02 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> I don't see how a highly specialized format for a particular task is
> a competitor to or even compatible with what Atom does. There's
> nothing in our charter that says we've failed if it isn't possible to
> do everything conceivably rela
On 4/6/05 9:26 AM, "Walter Underwood" <[EMAIL PROTECTED]> wrote:
> Yep. The could have used good ol' Infoseek sitelist.txt.
doesn't have revisit interval, doesn't have page-in-site priority, both
which seem important to google for scheduling purposes.
e.
On 29/5/05 7:09 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:
>>
>>
>>...
>>
>>
>>
> Or perhaps:
>
> ...
>
>
> :^)
>
>>
hmmm... seriously though, th
An Atom Entry can have XML content, right...
Consider this example:
http://...atom";>
...
the minimal Atom Entry
A minimal entry has only ...
...
Entirely legal, but who wants to bet the feed validator t
On 27/5/05 4:49 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> Replace "format-08" with "protocol-04" and you get it ;o)
> http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt
except I've been getting format-nn from http://atompub.org/... ;-)
ok, for those in the know, could you
On 27/5/05 4:14 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> protocol-04
btw, where can we find it?
e.
On 27/5/05 6:51 AM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote:
>> +1 to replacing atom:email and atom:uri with multiple real atom:link
>> elements (to allow titles).
>
> Yay. +1.
+1
that's elegant and clean, and seeing as we're unlikely to be seeing many
feeds with email addresses at all it'
>> I've mentioned this several times before and haven't had time to follow the
>> evolvement of the draft up until now, but as far as I can tell, atom:uri is
>> still in place in the specification... Do we really need a pace to have that
>> element renamed before the spec goes final?
>
> -1 to
On 26/5/05 5:20 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> (Also, do we have a definition for "Atom feed" that exists beyond a
> single instance of a "feed document"?)
we should have, but we don't.
similarly for "Atom Entry".
e.
On 25/5/05 2:45 PM, "Eric Scheid" <[EMAIL PROTECTED]> wrote:
>> I agree with this. I thought it was unusual to name a tag after a specific
>> technology rather than its intent (atom:email is an exception). In this
>> instance, I think atom:name, atom:r
On 25/5/05 6:57 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote:
> Consistency makes the format easier to understand and learn. Isn't that
> something worth stribing (and thus changing) for?
+1
On 25/5/05 2:34 PM, "James Cerra" <[EMAIL PROTECTED]> wrote:
> I agree with this. I thought it was unusual to name a tag after a specific
> technology rather than its intent (atom:email is an exception). In this
> instance, I think atom:name, atom:resource, or atom:link works better.
+1 atom:l
> 4.2.9 The "atom:link" Element
>
> The "atom:link" element is an empty element that defines a reference from an
> entry or feed to a Web resource.
did we want to prevent expressions like this:
e.
On 24/5/05 10:36 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> On 5/23/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>> On 24/5/05 9:56 AM, "Graham" <[EMAIL PROTECTED]> wrote:
>>> (unrelated question: what's with this plus sign &q
On 24/5/05 9:56 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> I'd say it draws from atom:source OR atom:feed.
>
You meant atom:source XOR atom:feed?
> atom:feed should not be used if atom:source exists, even if it doesn't
> contain an atom:author, which it SHOULD.
>
(well, it SHOULD, unless ato
On 24/5/05 9:23 AM, "Justin Fletcher" <[EMAIL PROTECTED]> wrote:
> Ah yes; quite correct and quite clearly stated in the draft. Thanks for
> pointing that out, sorry for redundant question :-)
No, don't be sorry. We all know way too much about the spec text, getting
outsiders to interpret what w
On 24/5/05 9:02 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> The problem is mostly when there are author(s) without contributor in
> the feed (resp. entry) and contributor(s) without author in the entry
> (resp. feed).
> Is the entry author-less (resp. contributor-less) or is it inheriting
>
On 24/5/05 4:14 AM, "Justin Fletcher" <[EMAIL PROTECTED]> wrote:
> As I understand it, the intention is that atom:author within atom:feed
> applies to all child atom:entry elements; that is, the value is inherited.
> This being the case I have a dilemma with a feed I would like to aggregate
> from
The question of inheritance of author/contributor from feed into entry needs
to be disambiguated. I looked from the format-08 text and found that we
already have reasonable wording in section 4.2.4 (The "atom:copyright"
Element). There is also a hint in section 4.2.11 (The "atom:source" Element)
On 23/5/05 3:18 PM, "Roger B." <[EMAIL PROTECTED]> wrote:
> With that in mind, what are the actual benefits of atom:modified over
> atom:updated? The end result will always be identical, unless I'm
> missing a crucial, well-hidden point.
atom:updated is predicated on a new feature yet to be buil
On 23/5/05 3:22 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> Antone Roundy suggests:
> +1 make atom:author plural
> +1 keep atom:contributor
> punt bylines to an extension
>
> To me that sounds like the simplest thing that can possibly work,
> and looks like it hits the 80/20 mark. It also
On 23/5/05 8:53 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> Yeah, I was startled just now to realize that there's nothing there
> to say that the feed-level author applies to entry-level when it's
> not specified at the entry level. The intent seems pretty clear;
> entry-level overrides source-l
On 23/5/05 6:01 AM, "David Powell" <[EMAIL PROTECTED]> wrote:
> We should add language that specifically states that the value of
> atom:feed/atom:author is not a shortcut for specifying
> atom:entry/atom:author - if that is what we mean.
+1 for disambiguating either way.
e.
On 22/5/05 10:09 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>>> What document is impossible to express with the current syntax?
>>
>> At this point, it's impossible to express anything, since several of
>> us are no longer sure what the meanings of atom:author and
>> atom:contributor are mean
Paul/Tim,
please advise:
(1) if the format spec succeeds last call, will it not sit in limbo until
the other specs which it relies upon also go into last call?
(2) if, in wrangling the protocol spec, we realise that something is broken
in the format spec, does IETF process allow us to recall t
On 22/5/05 1:10 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> There is no requirement that your feed change whenever
> you modify your posts.
+1
On 22/5/05 3:38 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> The problem with the example you gave is that it suggests that even entries
>> with just the one author/contributor would need two person constructs in the
>> entry, or maybe just the one ... either way it's confusing.
>
> No, it do
On 22/5/05 7:49 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> Atom should support atom:modified to permit the temporal-ordering of
>> members of sets that share the same atom:id and atom:updated values. This
>> has nothing to do with versioning.
>
> What does atom:id have to do with t
On 22/5/05 5:13 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> Making up requirements after last call is out of order.
Not so...
Paul Hoffman wrote:
> New issues for the format spec are now being brought up, issues that
> existed *before* the WG Last Call, much less the IETF-wide Last Call.
>
On 22/5/05 4:46 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote:
> Thomas Broyer wrote:
>> +1 on allowing multiple atom:author
>> -1 to dropping atom:contributor
>> -1 to renaming atom:author
>
> +1 to that.
I'm +0.5 to all that ... the sticky problem is just how do we insert an
authorship st
Here's an abbreviated feed:
Raggett, D, Hors, A, and I Jacobs
Dave Raggett
Arnaud Le Hors
Ian Jacobs
Homer Simpson
Marge Simpson
Barney Rubble, Esq
Simpson, H J, and D Raggett
Dave Raggett
101 - 200 of 450 matches
Mail list logo
