James M Snell wrote:
I'm perfectly happy with leaving previous and next free of any semantics
right now and letting the market sort things out. If more specific link
relations prove to be necessary, then so be it, define the more specific
link relations. If the market can get by with
James Holderness wrote:
Thomas Broyer wrote:
As I already explained, paging is orthogonal to the incremental nature
of a feed. An incremental feed will be chunked as explained in Mark's
current Feed History draft (just use an atom:[EMAIL PROTECTED]previous]
instead of the fh:prev
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/history to
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
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,
* Henry Story [EMAIL PROTECTED] [2005-10-24 12:00]:
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)?
By my understanding, incremental is the default semantic for a
feed, so to make it clear that that’s what yours is you
Eric Scheid 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)
link rel=enclosure type=audio/mpeg
href=http://example.com/file.mp3;
x:alternate
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
Hmm.. the more I think about this and the more we discuss it, the less I
think I like link[rel=profile]. While the URI of the profile
reference should be dereferenceable, most of the time the profile value
is going to be used as an
Thomas Broyer wrote:
I beg to differ. I think the incremental state of a feed is very relevant
to paging. If the aggregator does not know that a feed is non-incremental
it will not be able to process the feed document in a meaningful manner.
Yes, but that's orthogonal to paging.
I think I
On Oct 24, 2005, at 8:13 AM, James Holderness wrote:
With what we have so far we can do incremental feed archives; we
can do at
least some form of searching; we can do non-incremental feeds (of
the Top
10 variety) with history. I think that's a good start.
But we also want paged
On Oct 23, 2005, at 6:45 PM, James Holderness wrote:
James M Snell wrote:
1. Can a profile element appear in an atom:feed/atom:source? If
so, what does it mean? I think it should with the caveat that the
profile attribute should only impact the feed and should not
reflect on the
On Oct 24, 2005, at 5:18 AM, James Holderness wrote:
Eric Scheid 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)
link rel=enclosure type=audio/mpeg
Joe Gregorio wrote:
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
Hmm.. the more I think about this and the more we discuss it, the less I
think I like link[rel=profile]. While the URI of the profile
reference should be dereferenceable, most of the time the profile value
is going to
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP documents[1].
-joe
[1] http://www.gmpg.org/xmdp/
Perhaps they can, but that wouldn't always be desirable. Consider this
scenario: Somebody writes a program that searches Google, scrapes the
HTML results, and publishes them as an Atom feed. My purpose in
subscribing to the feed is not to be alerted when a new webpage is added
to page
Antone Roundy wrote:
Here's a final option--is it legal? Is it better or worse than (a) in
any ways?
(d)
link rel=enclosure type=audio/mpeg href=http://example.com/
file.mp3
link rel=alternate type=application/ogg href=http://
example2.com/file.ogg /
/link
I'm not completely sure
On Oct 24, 2005, at 11:16 AM, James Holderness wrote:
A more sensible approach would be a single feed document containing
the top N results (where N is manageable in size). You could
subscribe to that as a non-incremental feed and you would know at
any point in time which were the top 10
The concept of reusing atom namespaced elements as extensions inside
other atom namespaced elements has come up before and has generally been
frowned upon.
James Holderness wrote:
Antone Roundy wrote:
Here's a final option--is it legal? Is it better or worse than (a)
in any ways?
At 12:45 PM 2005-10-24, Joe Gregorio wrote:
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP
* James M Snell [EMAIL PROTECTED] [2005-10-22 17:20]:
(a)
link rel=enclosure type=audio/mpeg href=http://example.com/file.mp3;
x:alternate type=application/ogg href=http://example2.com/file.ogg; /
/link
(b)
link rel=enclosure type=audio/mpeg
href=http://example.com/file.mp3; /
link
On Oct 24, 2005, at 1:48 PM, A. Pagaltzis wrote:
I have a completely different proposition.
(e)
link
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
/
link
* 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. How about this:
link rel=enclosure type=audio/mpeg href=http://example.com/
file.mp3 xml:id=x-file
altlink:mirror
Hi Mark,
Mark Nottingham [EMAIL PROTECTED] wrote:
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
Antone Roundy wrote:
Interesting. Filling an attribute with a list of URIs doesn't really
appeal to me though.
Me neither. Something feels wrong about that. If you want a concrete reason,
it requires extra parsing whereas everything else would be automatically
parsed by the XML library.
* James Holderness [EMAIL PROTECTED] [2005-10-25 00:00]:
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 of nested elements
On Oct 24, 2005, at 2:59 PM, 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. How about this:
link rel=enclosure type=audio/mpeg href=http://example.com/
file.mp3 xml:id=x-file
As I said before, if the WG can reach consensus, I'm happy
with any old term. I hadn't seen Mark's proposal till a few
days ago, and a mention in an xml.com does not, in my
opinion, a spec-in-stone make.
My only pushback on next is that to me, it seems counterintuititive
-- same as
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're back to
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 changed?
e.
On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
link
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
/
link
rel=alternative-enclosure type=application/ogg
Eric Scheid wrote:
On 25/10/05 5:48 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
link
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
/
link
rel=alternative-enclosure
* Antone Roundy [EMAIL PROTECTED] [2005-10-25 00:35]:
2) You can break lines between elements, but you can't inside
an attribute, so it's better for display for humans.
That’s not what the XML spec says.
What if someday somebody does come up with a non-enclosure use
for this (which hardly
On Oct 24, 2005, at 9:59 PM, A. Pagaltzis wrote:
* Antone Roundy [EMAIL PROTECTED] [2005-10-25 00:35]:
2) You can break lines between elements, but you can't inside
an attribute, so it's better for display for humans.
That’s not what the XML spec says.
Doh! Who knows where I got that idea.
On 25/10/05 1:12 PM, James M Snell [EMAIL PROTECTED] wrote:
+1 to Eric's -1. Let's keep it simple.
link rel=... type=... href=...
x:alternate type=... href=... title=... /
/link
I'm also liking it from another angle...
With some of the other approaches dumb clients do harm to others,
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 of nested
35 matches
Mail list logo
