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 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
* 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 har
Eric Scheid wrote:
On 25/10/05 5:48 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
http://example.com/file.mp3";
encl:mirrors="http://www2.example.com/file.mp3
http://www3.example.com/file.mp3";
xml:id="x-file"
/>
http://example2.com/file.ogg";
encl:alternative-to="x-file"
/>
-1
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'
> 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
> -- s
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:
http://example.com/
file.mp3" xml:id="x-file">
http://www2.example.com/file.mp3
* 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 eleme
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.
h
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
* 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:
>
> http://example.com/
> file.mp3" xml:id="x-file">
> http://www2.example.com/file.mp3"; />
> http://www3.example.com/fil
On Oct 24, 2005, at 1:48 PM, A. Pagaltzis wrote:
I have a completely different proposition.
(e)
http://example.com/file.mp3";
encl:mirrors="http://www2.example.com/file.mp3 http://
www3.example.com/file.mp3"
xml:id="x-file"
/>
http://example2.com/file.ogg";
encl:alternative-to
* James M Snell <[EMAIL PROTECTED]> [2005-10-22 17:20]:
> (a)
> http://example.com/file.mp3";>
> http://example2.com/file.ogg"; />
>
>
> (b)
> href="http://example.com/file.mp3"; />
> href="http://example2.com/file.ogg"; />
* Antone Roundy <[EMAIL PROTECTED]> [2005-10-24 18:10]:
> (c)
> http
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 wrote:
The concept of reusing atom namespaced elements as extensions inside
other atom namespaced elements has come up before and has generally been
frowned upon.
No big deal. I'm quite happy with your initial x:alternate proposal.
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?
(d
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 re
Antone Roundy wrote:
Here's a final option--is it legal? Is it better or worse than (a) in
any ways?
(d)
http://example.com/
file.mp3">
I'm not completely sure yet, but I'm quite partial to this approach.
My only suggestion would be using rel="enclosure" on the inner links rather
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 20
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://
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
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)
http://example.com/
file.mp3">
http://examp
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 individua
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 non-incr
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 se
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 i
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)
href="http://example.com/file.mp3";>
http://example2.com/file.ogg";
/>
(b)
http://example.com/file
* 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 y
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,
Am 23.10.2005 um 23:34 schrieb Mark Nottingham:
On 23/10/2005, at 1:04 PM, Peter Robinson wrote:
I prefer 'subscribe' because it better describes the meaning and
intention behind the link, but I can live with 'current' if that is
the
consensus.
Well, Tim seemed to have a pretty strong -1
On 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
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:pr
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 g
36 matches
Mail list logo
