On 20/3/07 9:00 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:
> Also, is there a standard way to discover the collection associated with a
> feed? (Given that, if there is an IETF or WHAT-WG way to discover feeds,
> there's an obvious way to discover collections... but I'm not clear on what
> tha
On 17/12/06 1:13 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> * Lisa Dusseault <[EMAIL PROTECTED]> [2006-12-16 02:15]:
>> Since clients post Atom entries and other clients retrieve
>> them, it seemed reasonable to want to extend Atom
>> client-to-client. If I used "AtomFu" client that was able
On 17/12/06 2:20 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
>> I guess I'm assuming that one would want clients to be able to
>> extend Atom unilaterally.
>
> That doesn't seem to have been a design goal for the WG. To the
> extent that the issue never came up in the discussion.
Not sure exactl
On 15/12/06 7:29 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote:
> Besides, if you want to do fancy thing with a member, simply post a
> media resource which is an atom entry. This won't be modified by the
> server and will solely be treated a media resource.
promise? does the spec support
On 14/12/06 3:23 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them
> defined, registered, and "ready to use.")
> 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml"
> 3) New specifications MAY require that
On 12/12/06 5:56 AM, "Kyle Marvin" <[EMAIL PROTECTED]> wrote:
>> application/atom+xml; type=entry
>> application/atom+xml; type=feed
> I believe other UA-visible Atom document syntax qualifiers will be
> needed/coming downstream. For example. ones describing the expected extension
> model(s) of
On 11/12/06 2:26 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
> Adding an optional parameter that indicated an entry or
> a feed would be a more elegant solution:
>
> application/atom+xml;type=entry
> application/atom+xml;type=feed
I certainly agree it would be more elegant.
A more pragmati
On 6/12/06 5:06 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>> Would an agent finding multiple atom:content elements inside the one entry
>> consider that a problem (other than it being a spec violation)?
>>
>> Are XML processors optimised for the fact that any given attribute can only
>> occ
On 6/12/06 4:32 PM, "Mark Baker" <[EMAIL PROTECTED]> wrote:
> Or, are there applications which only process entry documents and not
> feed documents?
That would be unusual. I can imagine though that an application would easily
be designed to expect only entry documents for specific situations. A
On 6/12/06 3:52 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Not necessarily. Sure, it might be the same parser code, but not
> necessarily the same bit of code using the parser. Look at the way
> Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry
> documents versus Fe
On 1/12/06 5:21 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> 5) Create a new media type for entry documents, and use @rel values
> to solve issues that doesn't solve:
>
> +/- Messy territory
>
>
> If we were starting from scratch, I'd probably vote for #1. Since
> we're not, I'd vote for
On 30/11/06 5:39 AM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> would that not be solvable by
>
>
not if you want to do this:
where 'something-else' might be 'comments' or 'history' or 'unexpurgated' or
'disemvowelled' or many other as yet unknown opaque-strings, some of which
would be used
On 24/11/06 9:28 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> "Being a syndication feed" is expressed by the media type, there's no
> need for a 'rel' value.
I disagree, but for slightly different reasons. Consider these two links:
They are both Atom Feed Documents, but the forme
On 22/11/06 11:22 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> My preference would be to maintain the de facto standard that is already
> in use by countless sites. I'm just as annoyed as you are about the
> ambiguity in the mime type but in this case I think what's currently
> deployed trum
On 22/11/06 12:23 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> -1 to any changes that would be incompatible to existing dead
> draft, at any time.
agree, I too prefer no incompatibilities, and I don't see what I proposed as
being incompatible (slap me if I'm wrong).
> -1 also to changing the
On 18/10/06 8:07 AM, "Lisa Dusseault" <[EMAIL PROTECTED]> wrote:
> Extensions
>
> When the client puts extension elements in a MER, MUST the server store those
> unrecognized extension elements? I think the answer to this is actually that
> servers often do not and should not be required to do
On 4/10/06 3:44 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Either way, the behavior of the dir on the anchor is unmodified and
> standard (X)HTML rules apply.
so how might you code this:
here is some ltr text, with a link with
rtl-text which links to a
document which is ltr-te
On 4/10/06 1:03 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>>> A dir="rtl" on the content element establishes the base direction for
>>> the content but, just as with xml:lang, the content itself can override
>>> the value using whatever mechanisms are native to the content type.
>>
>> xml:l
On 3/10/06 11:44 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> If the default direction for the entire document is RTL, allowing that
> to be established at the feed or entry element level can save some
> effort adding the appropriate controls to every text element.
so @dir is to be inherited
On 2/10/06 5:01 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> I think we should move the format to Draft Standard by clearing up any
> errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
> in XHTML.
add @attr where?
e.
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 ins
When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?
For example: Corporate Communications prep a release and they stamp it with
a release date of Monday 4 PM ... but I don't see this release update until
I get into the office at 2 PM Tuesday, and thus I
On 27/7/06 7:42 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
>> what would happen if you used conneg on the @rel='self' link (to the
>> document), asking for a different language?
>
> You mean, sending an Accept-Language request-header?
>
> 406 Not Acceptable or return the entry even if it d
>> This took me quite a while to think through, but in the end I
>> agree. Translations of a resource will often have slightly different
>> contents in terms of the semantics of what is said, so I'd give them
>> different ids.
what would happen if you used conneg on the @rel='self' link (to the
On 30/6/06 1:34 AM, "Bill de hÓra" <[EMAIL PROTECTED]> wrote:
> Which are clients supposed to respect in a conflict, the
> Content-Language header or the xml:lang, ie, does XML On The Web Failing
> Miserably, Utterly, And Completely extend to Content-Language+xml:lang?
xml:lang, if you think of
On 10/6/06 12:02 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> In the Feed License Draft, feed's a licensed independently of their
> contained entries. There is no interaction between the licenses.
Ah, no inheritance. Makes sense really, since if that was in the spec it
would fail for aggreg
On 9/6/06 4:23 PM, "Karl Dubost" <[EMAIL PROTECTED]> wrote:
> 1. Feed composed with multiple sources with different licenses.
> When a feed aggregator creates a feed from different sources
> (feeds) with different licenses, what should be the license of the
> resulting feed?
>
> feed (licens
On 17/5/06 10:47 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I have to say at first blush I don¹t see why it should not work,
> so I find your thought experiment quite amusing.
this should be amusing too:
...
e.
On 18/5/06 1:36 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote:
> Apache would respond: "well yes the file has
> changed on the disk so here it is" when in fact the content of the feed
> has only changed for the number of comments of an entry.
so?
we have atom:updated to help aggregators
On 17/5/06 10:47 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> ...
>>
>
> You mean `hreflang`, not `xml:lang`, right?
I also meant there to be different hrefs too :-(
...
e.
On 17/5/06 10:47 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> You mean `hreflang`, not `xml:lang`, right?
oops, yes.
> I have to say at first blush I don¹t see why it should not work,
> so I find your thought experiment quite amusing.
:-)
On 17/5/06 11:38 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> This will be fixed in the next revision of the draft. The short answer
> is: every "replies" link MUST be processed independently of any others.
> That is, the feed consumer MUST NOT assume that multiple replies links
> are all ju
On 1/5/06 5:55 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> That said, however, we end up with a
> problem when we have one spec that says next points backwards in time
> (APP), one spec that says next points forwards in time (feed history)
> and one spec that says next is just another page o
On 1/5/06 2:25 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> While I'm sure the other James may have his own particular set of
> issues, the one pain point for me with the history spec is the use of
> the "previous" link to point back in time. This runs counter to the use
> of the previous li
On 22/4/06 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Where that gets nasty, of course, is when the href
> is relative and xml:base is being used to set the Base URI. Publisher
> would need to make sure that the href/ref combo match up properly
Would this be considered a "match"?
On 13/4/06 6:59 PM, "David Powell" <[EMAIL PROTECTED]> wrote:
> But what would processors do with an atom:link? Atom Protocol uses
> "edit", there have been calls for a "stylesheet". Links aren't
> necessarily things that you'd display to users (check HTML out for
> examples of that: favicon, P3P
On 13/4/06 8:02 AM, "David Powell" <[EMAIL PROTECTED]> wrote:
> In terms of the considerations to the interoperability of running
> code, thr:replies seems to beat atom:link in every way. It even
> manages to be more concise (you don't need the @rel), and you wouldn't
> need to put thr:count and
On 1/4/06 12:24 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> I think you might get more
> involvement if the tests were easier to use though. By that I mean tests
> that say exactly how they should be interpreted and that you can see at a
> glance whether you've got a pass or failure. Havi
On 31/3/06 3:08 PM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
>> The escaped HTML content contained within the content element that
>> David was originally concerned with is more than likely a copy of
>> all or part of the elements and content contained inside the body
>> tag of the external doc
On 24/3/06 4:42 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> I'm getting the data by scraping an html page, so I'm expecting
>> it to be acceptable html code, including html entities.
>
> Then decode the entities to a Unicode string and emit the feed as
> Unicode. Simplest thing that will wo
On 24/3/06 3:21 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote:
>>
>>
> Even if it was "HTML" you couldn't really use the entity, could you? I think
> you have to use a character reference or the actual character instead, yes.
>
It's true that XML has only a half dozen or so entities defin
If I have an author with the name "Bertrand Café", is it acceptable to put
that into atom:author like this;
or should I be using the unicode numeric entity instead?
e.
iginal discussion I've stumbled across something extra that
makes xml:lang relevant for atom:name.
Seems that in writing Hungarian names, the pattern is always surname
followed by forename - e.g. Bartók Béla, where Béla is the personal name and
Bartók is the family name.
While common western
On 2/2/06 12:51 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> Then again, I can¹t think of interesting
> information to put in the referrer of regular feed poll requests,
> but maybe my imagination is just too limited here.
Who said the aggregator would be limited to only doing regular feed po
On 31/1/06 1:27 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> Actually I was thinking just a regular href and type. For example:
>
> 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 consider
On 26/1/06 4:23 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>
On 22/1/06 7:42 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> No more than using the @rel value (is a feed an alternate for a
> single-entry HTML page?).
Depends on what you mean by "feed". Do you mean a resource whose
representation is an Atom Feed Document, or do you mean a resource which
p
On 22/1/06 3:27 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>> But, I could be in the minority. Which WG members think we should work
>> on exciting new HTML link relations?
>>
>
> Wow. Nobody.
>
> Phil, could we get a new rev of the Autodiscovery I-D?
nobody likes a strawman.
e.
On 20/1/06 1:55 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
>> What autodiscovery links should I do on a web page that displays a
>> single blog entry, like this one?
>>
>> http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
>
> Actually on my blog each page has a feed associated w
On 20/1/06 12:32 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
> On 1/19/06, Phil Ringnalda <[EMAIL PROTECTED]> wrote:
>> Though at this point in this discussion, someone is always duty-bound
>> to point out that the only use of that HTML actually specifies,
>> for stylesheets, treats them as no
On 20/1/06 12:12 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> It's not a "problem". It works now, and no one is going to run out and
> change the running code. If someone did do "alternate entry", I can
> see implementations getting patches to ignore those.
and patches for "alternate replies"
On 20/1/06 8:31 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> First person to need the feature has to spec "alternate entry" instead
> of making everyone change to "alternate feed".
How is speccing "alternate entry" helpful?
That would *still* be considered an autodiscovery link to a "feed",
On 20/1/06 8:52 AM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
>> Why wouldn't this work?
>>
>> rel="alternate feed"
>> rel="alternate entry"
>> rel="alternate replies" (see [1])
>
> Because rel is a space separated list of link types:
>
> http://www.w3.org/TR/REC-html40/struct/links.html#adef
On 20/1/06 10:10 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> And someone else still uses Atom in yet another clever way.
Which is precisely why [EMAIL PROTECTED]"alternate",@type="atom+xml"] is an
*ambiguous* way of discovering atom Feeds ...
> It¹s just impossible to specify enough precise
On 20/1/06 10:10 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> Okay, so you have two alternates: one with comments, one without.
> That would be `rel="alternate"` in both cases, with
> `title="Entry"` in one of them and `title="Entry with comments"`
> in the other.
>
> This is semantically wea
On 20/1/06 8:08 AM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
> """
> The purpose of Atom autodiscovery is for clients who know the URI of a
> web page to find the location of that page's associated Atom feed.
> """
>
> Not an entry but a feed. The autodiscovery is unambiguous on what such
> a l
On 20/1/06 7:57 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>> Here is a link to a resource:
>>
>>
>>
>> Please explain how a tool can decide whether that is a link to a
>> document, or is a link to an document?
>>
>
> This is a general limitation of the media type definition, not
On 20/1/06 7:52 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> Here is a link to a resource:
>>
>>
>>
>> Please explain how a tool can decide whether that is a link to a
>> document, or is a link to an document?
>
> this is an excellent point. How does either Pace address it?
PaceDiff
On 20/1/06 7:05 AM, "Anne van Kesteren" <[EMAIL PROTECTED]> wrote:
>> Please explain how a tool can decide whether that is a link to a
>> document, or is a link to an document?
>
> Why is that relevant?
umm ... "autodiscovery" ???
or are you saying that links to Atom Entry Documents would/sh
On 20/1/06 5:13 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> But we already have a name for doing that: it¹s called ³linking
> to something.² Now, it¹d be useful to encourage people to add
> `type` attributes to their `` links, so tools could find them
> just by looking at the page without spi
On 17/1/06 2:21 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> the media resource is supposed to be stored external to
> the collection feed and referenced via a content src link
hmmm ... premature optimisation due to common use case of binary content?
e.
On 16/1/06 5:29 PM, "Graham Parks" <[EMAIL PROTECTED]> wrote:
> Except no one bothered to tell the aggregator writers they'd have to
> implement this, so no it's not safe.
so atom is good for schlepping documents about, but not for elements of
documents (with two exceptions) :-(
e.
On 16/1/06 3:46 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> Thus, in the same sense I might have elsewhere a collection of
>> images, I have here a collection of atom categories.
>
> That doesn¹t even work, because this is invalid:
>
>
>
>
>
>
>
On 16/1/06 2:09 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> The one time I'd think it might be safe is with XHTML (as I mentioned in a
> previous message) since Atom processors are already required to handle XHTML
> fragments in the content element. Anything else would be highly risky unl
On 16/1/06 1:57 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
>>
>> ...
>>
>>
>>
>>
>>
>
> Heh.. another typo methinks ;-)
grrr! TooEarly - SufficientCoffee = Typos
e.
On 16/1/06 1:07 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> I personally assumed that the was an unintended error..
> after accounting for such, the example is valid.
Yes, that was a typo.
But I'm not so sure it's valid now, because of the SHOULD clause below:
per rfc4287 section 4.1
On 16/1/06 12:40 PM, "Elliotte Harold" <[EMAIL PROTECTED]> wrote:
> No. It's not even well-formed much less valid.
ignore the typo.
e.
Is this a valid atom entry?
[...elided...]
a snippet of foo xml
http://xmlns.com/foo/0.1/";>
King George
That is, is a partial xml document valid inside the atom:content element?
What about xml formats whose spe
On 21/12/05 3:53 PM, "Michael Stillwell" <[EMAIL PROTECTED]> wrote:
> Is the element the right way to do this?
the atom:source element is the right way.
e.
On 27/10/05 4:09 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> It would say descendents if it meant descendents, no?
not if it was speaking in more general terms.
e.
Section 4.1.2 of the Atom Syndication Format spec states this:
"This specification assigns no significance to the order of
appearance of the child elements of atom:entry."
Is this referring to the immediate children only of atom:entry, or of all
descendents?
I'm hoping for the former, ot
On 26/10/05 4:18 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
> The only thing I would change is the name of x:mirror/@title to make
> it clear that it isn't intended(?) to replace the parent link's
> @title. My current favorite name is "label".
+1
On 25/10/05 5:06 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> Is providing a @title an option that a lot of people would use
> and/or someone out there cannot do without?
In Atom 1.0 not enough deployment to say
In HTML ... *lots* of current practice of labelling mirrors with the org
na
On 25/10/05 5:17 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
>>> http://example.com/
>>> file.mp3" xml:id="x-file">
>>> http://www2.example.com/file.mp3"; />
>>> http://www3.example.com/file.mp3"; />
>>>
>>>
>>
>> It¹s a lot more verbose and you have to fiddle with nesting.
>>
>> Wha
On 25/10/05 4:59 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I am asking if is there a generic way for an application to
> implement alternate-link processing that gives sensible behaviour
> for any type of main link.
couldn't get more generic than that.
read it as: here is a link (
On 25/10/05 8:13 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> If you want a concrete reason, it requires extra parsing
>> whereas everything else would be automatically parsed by the
>> XML library.
>
> You have to split on whitespace; that¹s much easier in my book
> than finding a nodeset o
On 25/10/05 1:12 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> +1 to Eric's -1. Let's keep it simple.
>
>
>
>
I'm also liking it from another angle...
With some of the other approaches dumb clients do harm to others, and while
smart clients do no harm they don't get anything which dumb
On 25/10/05 5:48 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>rel="enclosure" type="audio/mpeg"
> href="http://example.com/file.mp3";
> encl:mirrors="http://www2.example.com/file.mp3
> http://www3.example.com/file.mp3";
> xml:id="x-file"
> />
>rel="alternative-enclosure" type="a
On 25/10/05 8:13 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> You have to split on whitespace; that¹s much easier in my book
> than finding a nodeset of nested elements and iterating over it.
I recall people screaming about "micro-parsers" before for a different
attribute. Has anything change
On 25/10/05 3:43 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> My only suggestion would be using rel="enclosure" on the inner links rather
> than "alternate". There will be some Atom processors [1] that won't be able
> to tell the difference between an inner link and an outer link.
and we'
On 24/10/05 5:31 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> This has not yet proven to be really needed (e.g. the Top 50 web site I
> saw didn't provide archives of previous rankings).
> When there'll be such a need, then we'll define a new link relation (I
> already proposed "archives"/"hi
On 23/10/05 1:14 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> The challenge with using alternate to point to files of different types
> is that why would someone do (a) when they can already do (b) without
> the help of a new extension
>
> (a)
> http://example.com/file.mp3";>
> http://exampl
On 22/10/05 1:20 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>
> I like this a lot. You get fallback support when a link goes down as well as
> the ability to download from multiple sources simultaneously for extra
> speed. For this to work, though, it's vital that
On 22/10/05 4:25 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> On consideration, I am -1 to rel="subscribe". The reason is this:
> one of the big potential value-adds Atom brings is a standards-
> compliant way to do one-click auto-subscribe, via
> You are proposing to introduce a which
> is ther
On 22/10/05 4:48 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> Note the caveat, "with the same combination of type and hreflang
> attribute values". The idea is to prevent a single license from being
> appearing more than once.
>
>>>Multiple license link relations MAY be used to indicate
On 22/10/05 1:33 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> First, rel="self" is going to be implemented by most everything
> that groks Atom 1.0 in order to support one-click subscription,
> if applicable, right? Whereas this new relationship might not
> find such wide-spread support.
I be
On 21/10/05 11:57 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> I'm puzzled by this one. I thought that if you wanted to subscribe
> to a feed then, well, you would subscribe to a feed. I must have
> missed the discussion.
This arose during the discussion of Atom Feed Documents as archives. It w
+1 to all
>>> Ok, somehow this slipped under the radar on me during
>>> my first reading. -1, as I prefer next, as in, the *next*
>>> document in a chain of documents.
>
>> "No matter which direction you head in, no matter which way the chain is
>> sorted, the next document is always "next", so that's not
On 20/10/05 3:12 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
> b) a generic relation, e.g., "previous"
+1
On 19/10/05 10:58 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>>> I already have code that uses "next" for this. Why do we want to change it?
>>
>> Why did you choose "next"?
>
> Because that is what's already been deployed and what my software uses.
-1.
Someone else made a poor choice*, y
On 19/10/05 9:13 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> rel: next
> definition: A URI that points to the next feed in a series of feeds.
> For example, in a reverse-choronological series of feeds, the 'next'
> URI would point deeper into the past.
How will your code cope with a forward-
On 19/10/05 7:06 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
>> The word 'archives' is too general though. May I suggest @rel="history"
>> instead?
> I'm not a native English speaker so
>
> but what's wrong with "archives"?
IIRC, you wanted a new link relation specific to historical style
On 19/10/05 5:38 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> I already have code that uses "next" for this. Why do we want to change it?
Why did you choose "next"?
e.
On 18/10/05 5:51 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> How can there be more than one paging semantic applied to a single feed?
> If a feed (not feed document) is a set of entries (sorted by whatever
> metadata: updated, priority, relevance, etc.) and you publish chunks as
> many feed
On 18/10/05 6:14 PM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> Yes, and navigating through the historical states of the feed resource is
> not paging, it's more like having access to archives.
>
> I was thinking about proposing yet another link relation "archives": in
> the general use case,
On 18/10/05 3:32 PM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
> Such agents should also take care to detect circular
> references between feeds when following them.
s/between feeds when/between feed documents/
otherwise +1
e.
On 18/10/05 9:53 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:
> So what happens when you need the rel="self" (as currently defined)
> of an archive feed?
The current definition being ...
The value "self" signifies that the IRI in the value of the href
attribute identifies a resour
On 18/10/05 9:07 AM, "Thomas Broyer" <[EMAIL PROTECTED]> wrote:
> Depends whether @rel="self" was really meant for subscribing and the
> spec wording is not precise enough about it; this could then be fixed
> with an errata rather than create a new link relation
IIRC, it came into existence to
On 18/10/05 7:10 AM, "James Holderness" <[EMAIL PROTECTED]> wrote:
> Personally I wouldn't care at all except for one reason. There exists a
> published "specification" that defines "next" as pointing to the next most
> recent archive, and at least one feed that follows that spec. Whatever is
> d
1 - 100 of 450 matches
Mail list logo
