date:20060502


* James M Snell [EMAIL PROTECTED] [2006-05-02 07:15]:
 As you can see from the example, the thr:replies/@ref attribute
 points to an atom:id value, and not the URI used by the link.

So fetching and parsing all relevant links is the only way to
know which `thr:replies` element applies to which link, and no
way to indicate a global reply count is available?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


Aristotle,

I'm not 100% happy with it yet so it may change at least one more time.
 But I did want to get this out and in front of y'all to get initial
reactions.

I'll go ahead and make the ref attribute optional.  Regarding the ref
vs. href, issue, I really want to discourage client implementors from
using the thr:replies as a link to the comment feed.  Having and href
attribute in there is inviting headaches.  Suggestions on possible ways
of wording the spec / attribute naming / etc would be greatly appreciated.

- James

A. Pagaltzis wrote:
 * James M Snell [EMAIL PROTECTED] [2006-05-02 07:15]:
 As you can see from the example, the thr:replies/@ref attribute
 points to an atom:id value, and not the URI used by the link.
 
 So fetching and parsing all relevant links is the only way to
 know which `thr:replies` element applies to which link, and no
 way to indicate a global reply count is available?
 
 Regards,

Re: Entry types


Hey David,

Just some responses to your random thoughts.  My goal is not to argue
that the category approach is best, but only to state the rationale
behind what we've done to this point.

David Powell wrote:
 Monday, May 1, 2006, 8:40:57 PM, James Snell wrote:
 
 I'm wondering if it would make sense to have a single common type
 scheme that could be used consistently across implementations.
 
 random thoughts
 
 Type seems a bit vague, this seems to be mainly about describing how
 an entry should be processed.  A few possible ways to do that:
 
 a) Using categories and a known categorisation scheme
 b) Using an ex:processAs extension
 c) Using domain specific extensions, eg contact:VCard /
 d) duck-typing, eg assuming that contact:firstName implies the type.
 

There are two reasons our implementation uses category to represent the
kind of entry.

1. To specify how the entry should be processed (e.g. our UI shows
comment entries differently than file entries)

2. To allow existing feed readers that understand the category element
to present that information to users.  For instance, when I load one of
our feeds in Liferea, I can see right away that an entry is a Task or a
Comment, or a File, etc, even tho Liferea knows absolutely nothing about
our particular application.

Looking at Sylvain's order of preference, I would switch c and a:

   In order of preferences: a, c, b, d

 I think that using category might be an overloading of the semantics
 of category?, I'm not sure, it probably depends on the circumstances.
 Category is really a summary of the set of real-world concepts the
 entry is about, it ought to be under control of the publisher. Typical
 Atom consumers will probably provide a UI to filter entries by
 category. Do consumers want the set of categories for an entry
 polluted with physical properties of the entry? This might be ok
 sometimes, but not in general.
 

With the category approach, I can group entries by Task, by File, by
Event, etc.  Note also that we're making judicious use of the category
scheme to differentiate the various types of categories.  For instance,
we have a type scheme, we have a visibility scheme (e.g. private,
public), we have a status scheme (e.g. completed, not-completed), we
have a tag scheme, etc.

None of the feed readers we've tested actually make good use of the
scheme attribute.  In fact, at least one attempts to use it as a
dereferenceable URI.  Hopefully, that situation improves.

 Can entries have multiple types? Like an entry that includes both the
 event details and contact details for the organiser? Will typical Atom

In our implementation no, but it generally, it's possible.

 infrastructures be able to dispatch entries to multiple processors, or
 will it be like MIME-types, where this is difficult (as in the
 dispatching of generic XML types based on namespace, or of RDF)?
 

I certainly hope not.  In our case, the entry typing is used to allow us
to present intelligent UI options to the user based on what kind of
thing the entry is.

 Microsoft has a screen saver sample [1] that uses Windows Feed
 Platform to display picture feeds. It does this without any typing,
 just by examining each entry in the feeds associated with the screen
 saver, and selecting the appropriate ones.
 
 [1] http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx
 
 I remember seeing a demo of a calendar feed that synced with Outlook,
 I suspect that that also relied on having the plugin decide which
 entries it was interested in, rather than the engine dispatch entries
 to specific plugins. Engine driven dispatching might be slightly more
 performant, but plugin driven dispatching is more flexible and doesn't
 need a well-known type extension to key off.
 
 Is it enough to go for the duck-typing approach, and not require
 explicit typing? But, what if all of the extensions for contacts are
 optional? What if some are shared with the extensions for
 appointments? If the rules for deciding on the type of an entry aren't
 specified, it might be more prone to interop problems, where one
 implementation detects an entry as a contact, and another doesn't. I
 suppose a quick vcard:* check is pretty easy with XPath.
 
 

I believe there is room for both.  For example, I certainly do not need
a type=podcast category to determine whether or not an entry contains a
podcast.  However, the category-based typing does prove useful when
differentiating different kinds of entries that otherwise have similar
or even identical structures.

For example,

  !-- a comment --
  entry
idtag:example.org,2006:1/id
titleA Comment/title
link href=http://example.org/foo; /
updated2006-05-02T12:12:12Z/updated
authornameJames/name/author
contentThis is a comment/content
category scheme=urn:entry:type term=comment label=Comment/
  /entry

  !-- a link --
  entry
idtag:example.org,2006:2/id
titleA link to some other page/title
link href=http://example.com/bar;

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-02 05:25]:
 On 5/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 * Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]:
  especially when changes requested by the community are met
  with hostility and channel flooding.
 
 Did this happen in more cases than the one I'm aware of?
 
 Yes.

Such as?

  When I read terms like more standard wrt the feed thread
  extension, it makes me cringe.
 
 There are obvious reasons why that one is better than the rag-tag
 group of RSS extensions...
 
 Disagree. There is no proof of that.

There is proof that the existing patchwork of RSS extensions is
insufficient. That is enough to convince me that an extension
which addresses their holes is useful.

If addressing holes in existing standards was unnecessary, then
RSS is good enough and the Atom was a giant waste of time.

 I disagree with many decisions in the draft, but that is
 because I think they are misguided, not because I dislike the
 person who wrote them. For instance, every other threading
 extension uses a simple element with a number to represent the
 number of responses.

That is just one case. I agree that the current setup in the FTE
is less than pretty, and I’d like it to change; but I see what
motivated the form of the provided features and so I consider
them incomplete rather than completely misguided.

 This is limited in theory, but in practice, such elements are
 so easy to deploy, they prove valuable.

I agree with that. (See my proposition elsewhere, which would
have provided this as a special case; it does bother me that the
revision that was just published does not provide for this.)

  for that excludes the IETF from defining the problem.
 
 How do you mean? (Question to be taken at face value. I
 honestly am not sure what you mean here.)
 
 
 Defining the charter, etc, etc. It's a good thing to do. Are
 there any WG members left who were around at that phase? I
 joined right around then...

You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Feed thread update


* James M Snell [EMAIL PROTECTED] [2006-05-02 17:00]:
 I'll go ahead and make the ref attribute optional.

I think that still needs to be accompanied with verbiage about
global vs local reply count though. There should be guidance on
what it means when elements both with and without `ref`
attributes are present on the same entry.

 Regarding the ref vs. href, issue, I really want to discourage
 client implementors from using the thr:replies as a link to the
 comment feed. Having and href attribute in there is inviting
 headaches. Suggestions on possible ways of wording the spec /
 attribute naming / etc would be greatly appreciated.

Okay, I can see that. Harumpf. Not happy; there has to be a way
to associate links directly with `thr:replies` elements and the
only other way than by comparing `href`s that I can think of is
to put a namespaced attribute on the link, which sucks for
reasons we’ve already been over.

Will have to read this revision and think about it.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions



On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


Such as?


Not appropriate for on-list discussion, sorry.


  When I read terms like more standard wrt the feed thread
  extension, it makes me cringe.
 
 There are obvious reasons why that one is better than the rag-tag
 group of RSS extensions...

 Disagree. There is no proof of that.

There is proof that the existing patchwork of RSS extensions is
insufficient. That is enough to convince me that an extension
which addresses their holes is useful.

If addressing holes in existing standards was unnecessary, then
RSS is good enough and the Atom was a giant waste of time.



I don't I follow your reasoning. We have namespaces so vendors can
create whatever they might like, without involving the standards
organization. I fail to see the point in rubber-stamping such things.



You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.


And WG chairs, etc, etc.

--

Robert Sayre

Re: Atom Rank Extensions


A. Pagaltzis wrote:
 * Robert Sayre [EMAIL PROTECTED] [2006-05-02 05:25]:
 On 5/1/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 * Robert Sayre [EMAIL PROTECTED] [2006-05-02 03:50]:
 especially when changes requested by the community are met
 with hostility and channel flooding.
 Did this happen in more cases than the one I'm aware of?
 Yes.

 Such as?


Aristotle, I appreciate the intention, but please don't bother. It is
painfully clear that Robert has no intention of adding anything of any
real value to the discussion.

As far as FTE is concerned, please understand that I am trying to find
the best way of accommodating a mix between The simplest thing that
could possibly work with The way things likely ought to work.  I
consider MSFT's decision to not preserve unknown foreign content to be
extremely shortsighted.

To contrast, in my implementation, supporting thr:when and thr:count as
attributes on link requires no additional code, I can simply
link.getAttribute(whenQname) and get the info I need.  With the
thr:replies element, to do it properly, I have to create a new extension
element, create a factory, register the extension with the parser, etc.
 Adding in the difficulties inherent in matching equivalent href values
between the atom:link and thr:replies element means that I'm having to
do a whole lot more work than what is required with the attribute
approach.  So much, in fact, that I'm fairly certain that folks will be
less likely to implement a FTE that incorporates the thr:replies
element. So if I seem grumpy and reluctant to change, please try to be
patient and understand.

- James

NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community

2006-05-02 Thread M. David Peterson



I can only assume that someone from Opera is on this list, and I'm not
even sure this is that big of a deal, but then again


From: http://my.opera.com/community/customize/widgets/info/?id=4021

This feed allows subscribing to an unlimited number of news feeds.
Supported formats: RSS 2 and  Atom 2 . Thus providing an advantage
over per-site news feed aggregators.
---

I realized Web2 is the hot new thing, but and RSS 2 is obviously not
an issue (well, not from the standpoint of improper promotion of the
so called version #) but if not mistaken, the Atom community will
never have the need for an Atom 2.0 spec, so it might be worth pinging
whomever developed the above widget to let them know they need to fix
this.

NOTE: Would have done so myself, but can't seem to find a place to
post a note other than through the ratings panel, and I can only
assume that, like the Fx community, the Opera community would prefer
that bug reports don't come through the ratings channel.

Thanks in advance!

--
M:D/

M. David Peterson
http://www.xsltblog.com/

Re: Atom Rank Extensions



On 5/2/06, James M Snell [EMAIL PROTECTED] wrote:


Aristotle, I appreciate the intention, but please don't bother. It is
painfully clear that Robert has no intention of adding anything of any
real value to the discussion.



???

--

Robert Sayre

Re: Atom Rank Extensions


* James M Snell [EMAIL PROTECTED] [2006-05-02 19:45]:
 A. Pagaltzis wrote:
  Such as?
 
 Aristotle, I appreciate the intention, but please don't bother.
 It is painfully clear that Robert has no intention of adding
 anything of any real value to the discussion.

I know. However, I despise politics and old boys clubs and prefer
the merit of my decisions to be self-evident, so I’m avoiding any
assumption of any axe to grind behind his behaviour, to see what
should be addressed and how. If there is any meritorious concern
in his objections, I’d like it addressed, regardless (despite?)
of who brought them up and how.

 As far as FTE is concerned, please understand that I am trying
 to find the best way of accommodating a mix between The
 simplest thing that could possibly work with The way things
 likely ought to work.

Absolutely; I pushed for some of the compromises in the current
design myself.

 With the thr:replies element, to do it properly, I have to
 create a new extension element, create a factory, register the
 extension with the parser, etc. Adding in the difficulties
 inherent in matching equivalent href values between the
 atom:link and thr:replies element means that I'm having to do a
 whole lot more work than what is required with the attribute
 approach.

I have to say that your architecture sounds rather heavyweight,
though it could be close to the norm for people who don’t work at
the DOM level. I don’t have experience with that.

To give my experience from the other end, all my work has been at
the DOM level, where the approaches differ only minimally.
libxml2 provides a `getBase` method which makes xml:base support
effortless; when I use XSLT to transform Atom feed documents, I
wrap it and register it as an extension function, so matching
`href`s is trivial:

xsl:key
name=link-to-uri
match=atom:link
use=uri:resolve( uri:base( . ), @href )
/

 So much, in fact, that I'm fairly certain that folks will be
 less likely to implement a FTE that incorporates the
 thr:replies element.

I can see that. Hrmf. There’s gotta be a better way…

I hope though that this also gives you an appreciation for
Robert’s complaint about the lack of a global reply count
provision. He’s right: for simple use cases that sidesteps a lot
of headaches on the consumer’s end.

 So if I seem grumpy and reluctant to change, please try to be
 patient and understand.

Yes, I see now how it comes about.

However, referring to above, plus what we know about the Windows
RSS Platform, please don’t forget the cases other than your own.

Let’s see if we can come up with something that is as simple to
implement as possible for everyone…

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions



On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


* James M Snell [EMAIL PROTECTED] [2006-05-02 19:45]:
 A. Pagaltzis wrote:
  Such as?

 Aristotle, I appreciate the intention, but please don't bother.
 It is painfully clear that Robert has no intention of adding
 anything of any real value to the discussion.

I know. However, I despise politics and old boys clubs and prefer
the merit of my decisions to be self-evident, so I'm avoiding any
assumption of any axe to grind behind his behaviour, to see what
should be addressed and how. If there is any meritorious concern
in his objections, I'd like it addressed, regardless (despite?)
of who brought them up and how.



I've been saying the same thing for weeks. I suppose it's par for the
course to handwave about them being strictly advisory, supply
circular definitions for the feature in the first place, claim no one
will be implementing the feature, then claim that someone is, etc,
etc. You know, stuffing an idea because of who proposed it. You can go
read the atom-protocol archives if you want more evidence of that.

The general pattern seems to be to sanctimoniously scold me for making
the suggestion, and then to adopt it with cosmetic changes.

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: Atom Rank Extensions




A. Pagaltzis wrote:
[snip]
 With the thr:replies element, to do it properly, I have to
 create a new extension element, create a factory, register the
 extension with the parser, etc. Adding in the difficulties
 inherent in matching equivalent href values between the
 atom:link and thr:replies element means that I'm having to do a
 whole lot more work than what is required with the attribute
 approach.
 
 I have to say that your architecture sounds rather heavyweight,
 though it could be close to the norm for people who don’t work at
 the DOM level. I don’t have experience with that.
 

Heavyweight?  It's Java. need I say more?

By do it properly, I mean being able to provide developers with an
interface that understands the thread extension, it's a difference between:

Option 1, which does not require adding any additional classes

  ExtensionElement el = entry.getExtension(thrReplies);
  int count = el.getAttribute(count);
  Date updated = AtomDate.valueOf(el.getAttribute(updated));

and Option 2, which does require adding additional classes

  Replies replies = entry.getExtension(thrReplies);
  int count = replies.getCount();
  Date updated = replies.getUpdated();

My implementation supports either.

Getting the resolved href's for the link and replies is simple.
Matching up all of the various equivalents is a pain.

  URI uri1 = link.getResolvedHref();
  URI uri2 = replies.getResolvedHref();
  // normalize and compare the uri's

 To give my experience from the other end, all my work has been at
 the DOM level, where the approaches differ only minimally.
 libxml2 provides a `getBase` method which makes xml:base support
 effortless; when I use XSLT to transform Atom feed documents, I
 wrap it and register it as an extension function, so matching
 `href`s is trivial:
 
 xsl:key
 name=link-to-uri
 match=atom:link
 use=uri:resolve( uri:base( . ), @href )
 /
 

Does your implementation properly handle the following (contrived) example:

entry xml:base=http://example.org/foo/bar;
...
link href=../comments.xml rel=replies /
thr:replies href=http://EXAMPLE.org:80/foo/bar/../comments.xml; ... /
...
/entry

I know for a fact that Java's built-in comparison functions for the URI
and URL classes do not.  I have to normalize the URI's after I resolve
them before I can compare them.

What's more, for each replies link, I need to iterate through all
available thr:replies elements, resolve, normalize and compare each href.

Pain.

It is possible that the spec could dictate that the thr:replies resolved
href attribute MUST match the link's href attribute
character-for-character, making the above example invalid.

 So much, in fact, that I'm fairly certain that folks will be
 less likely to implement a FTE that incorporates the
 thr:replies element.
 
 I can see that. Hrmf. There’s gotta be a better way…
 

;-) Yes, there is a better way, but y'all complained about it ;-)

(sorry, couldn't resist)

[snip]
 Let’s see if we can come up with something that is as simple to
 implement as possible for everyone…
 

As always, suggestions for spec text are always welcomed.

oh, and btw, draft -09 is now available.

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-09.txt

- James

Re: Atom Rank Extensions


Just a quick heads up.  To illustrate a simple example of feed rank bein
used, I put together an xslt that renders my Netflix Queue as an Atom
feed using the feed rank, feed history and MSFT simple list extensions.

http://tinyurl.com/nxzgh

Please excuse the tinyurl, the real URL for the feed is big and ugly
because it goes through the W3C online xslt servlet to produce the
result.  You can find the original URL on my blog:
http://www.snellspace.com/wp/?p=312

- James

James M Snell wrote:
 All,
 
 A new draft of the Feed Rank extension has been published.  Andreas Sewe
 has joined on as an author and has contributed significantly to this rev
 of the draft.  There are many updates to the extension that are worth
 highlighting.
 
 http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-09.txt
 
 First, the purpose of this extension is to provide a flexible means of
 ranking entries within a feed.  For instance, a feed might represent an
 ordered listing of items from a movie rental queue; or each entry in a
 feed might contain a five star review ranking; or each entry in the feed
 might represent a listing of a students graded homework assignment,
 where each rank represents the grade assigned to the work, etc.
 
 For example, when combined with Mark Nottingham's Feed History extension
 for marking a feed as complete, Feed Rank provides a good solution for
  representing a movie rental queue:
 
  feed xmlns=http://www.w3.org/2005/Atom;
xmlns:r=http://purl.org/syndication/rank/1.0;
idtag:example.org,2006:my_movie_queue/id
fh:complete xmlns:fh=http://purl.org/syndication/history/1.0/
title type=textMy Movie Queue/title
updated2006-05-01T12:00:00Z/updated
authornameJames/name/author
link rel=self href=queue.xml /
link href=queue.html /
r:scheme name=tag:example.org,2006:my_movie_queue
  label=Queue Position
  significance=descending
  r:range minimum=0 step=1 /
/r:scheme
r:scheme name=tag:example.org,2006:movie_reviews
  label=Customer Reviews
  signifiance=ascending
  r:range minimum=0.0 maximum=5.0
   step=0.5 scale=1 /
/r:scheme
entry
  idtag:example.org,2006:movies/chaplin/citylights/id
  title type=textCity Lights/title
  updated2006-05-01T12:00:00Z/updated
  link href=/movies/chaplin/citylights.html /
  summaryCharlie Chaplin's cassic film/summary
  r:rank domain=
scheme=tag:example.org,2006:my_movie_queue1/r:rank
  r:rank
domain=tag:example.org,2006:movie_reviews
scheme=tag:example.org,2006:movie_reviews4.5/r:rank
/entry
entry
  idtag:example.org,2006:movies/chaplin/moderntimes/id
  title type=textModern Times/title
  updated2006-05-01T12:00:00Z/updated
  link href=/movies/chaplin/moderntimes.html /
  summaryAnother Chaplin classic/summary
  r:rank domain=
scheme=tag:example.org,2006:my_movie_queue3/r:rank
  r:rank
domain=tag:example.org,2006:movie_reviews
scheme=tag:example.org,2006:movie_reviews3.5/r:rank
/entry
entry
  idtag:example.org,2006:movies/chaplin/thegoldrush/id
  title type=textThe Gold Rush/title
  updated2006-05-01T12:00:00Z/updated
  link href=/movies/chaplin/thegoldrush.html /
  summaryChaplin in a frozen wilderness/summary
  r:rank domain=
scheme=tag:example.org,2006:my_movie_queue2/r:rank
  r:rank
domain=tag:example.org,2006:movie_reviews
scheme=tag:example.org,2006:movie_reviews5.0/r:rank
/entry
  /feed
 
 While there are a variety of changes throughout the entire spec, the key
 differences in this draft lie in the definition of the Ranking Schemes.
  A Ranking Scheme is now defined as a set of discreet values and/or
 ranges.
 
 For instance, a typical U.S. grading scheme can be represented using a
 series of ranges representing percentage values:
 
  r:scheme name=tag:example.org,2006:grades
label=Percentage Grading System
significance=ascending
r:range label=F
 minimum=0.00
 maximum=0.59
 scale=2
 step=0.01 /
r:range label=D
 minimum=0.60
 maximum=0.69
 scale=2
 step=0.01 /
r:range label=C
 minimum=0.70
 maximum=0.79
 scale=2
 step=0.01 /
r:range label=B
 minimum=0.80
 maximum=0.89
 scale=2
 step=0.01 /
r:range label=A
 minimum=0.90
 maximum=0.99
 scale=2

Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community

2006-05-02 Thread Mihai Sucan



Le Tue, 02 May 2006 20:51:41 +0300, M. David Peterson  
[EMAIL PROTECTED] a écrit:




I can only assume that someone from Opera is on this list, and I'm not
even sure this is that big of a deal, but then again


From: http://my.opera.com/community/customize/widgets/info/?id=4021

This feed allows subscribing to an unlimited number of news feeds.
Supported formats: RSS 2 and  Atom 2 . Thus providing an advantage
over per-site news feed aggregators.
---

I realized Web2 is the hot new thing, but and RSS 2 is obviously not
an issue (well, not from the standpoint of improper promotion of the
so called version #) but if not mistaken, the Atom community will
never have the need for an Atom 2.0 spec, so it might be worth pinging
whomever developed the above widget to let them know they need to fix
this.

NOTE: Would have done so myself, but can't seem to find a place to
post a note other than through the ratings panel, and I can only
assume that, like the Fx community, the Opera community would prefer
that bug reports don't come through the ratings channel.

Thanks in advance!

--
M:D/

M. David Peterson
http://www.xsltblog.com/



Hello!

I happend to be subscribed to this mailing list. Just joined this week.

I am the author of the widget. Yes, my mistake. Appologies.

I'll update the widget and I'll ask the editors of My Opera community site  
to fix that.


I must make myself very clear, it was *not* my intention to use improper  
version number and to falsely promote Atom 2 support.


Thank you very much for posting this, yet I would have been glad if you  
would've contacted me first via my site.



--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community

2006-05-02 Thread M. David Peterson

Very cool! Thanks for the prompt reply :)

re: I must make myself very clear, it was *not* my intention to use improperversion number and to falsely promote Atom 2 support.

My apologies if I came across the wrong way... I wasn't meaning to call you out and suggest something evil had taken place... I have just seen things like this be taken to mean There's a version two on its way? or even something as simple as assuming that in fact, Atom 2 is the current version and simply accept, to then propograte this information. I simply wanted to make sure that this didn't take place.

Thanks again for the response and for taking the steps to get it fixed! :)

On 5/2/06, Mihai Sucan [EMAIL PROTECTED] wrote:
Le Tue, 02 May 2006 20:51:41 +0300, M. David Peterson[EMAIL PROTECTED]
a écrit: I can only assume that someone from Opera is on this list, and I'm not even sure this is that big of a deal, but then again From:
http://my.opera.com/community/customize/widgets/info/?id=4021 This feed allows subscribing to an unlimited number of news feeds. Supported formats: RSS 2 and Atom 2 . Thus providing an advantage
over per-site news feed aggregators. --- I realized Web2 is the hot new thing, but and RSS 2 is obviously not an issue (well, not from the standpoint of improper promotion of the
so called version #) but if not mistaken, the Atom community will never have the need for an Atom 2.0 spec, so it might be worth pinging whomever developed the above widget to let them know they need to fix
this. NOTE: Would have done so myself, but can't seem to find a place to post a note other than through the ratings panel, and I can only assume that, like the Fx community, the Opera community would prefer
that bug reports don't come through the ratings channel. Thanks in advance! -- M:D/ M. David Peterson http://www.xsltblog.com/
Hello!I happend to be subscribed to this mailing list. Just joined this week.I am the author of the widget. Yes, my mistake. Appologies.I'll update the widget and I'll ask the editors of My Opera community site
to fix that.I must make myself very clear, it was *not* my intention to use improperversion number and to falsely promote Atom 2 support.Thank you very much for posting this, yet I would have been glad if you
would've contacted me first via my site.--http://www.robodesign.roROBO Design - We bring you the future-- M:D/
M. David Petersonhttp://www.xsltblog.com/

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-02 22:00]:
 I've been saying the same thing for weeks. I suppose it's par
 for the course to handwave about them being strictly
 advisory, supply circular definitions for the feature in the
 first place, claim no one will be implementing the feature,
 then claim that someone is, etc, etc.

Yes. I thought those defences were very silly as well.

 You know, stuffing an idea because of who proposed it.

No, not just because of who proposed it, but also because of how.
You objection is not unreasonable, but you phrased it roughly as
“this is useless crap that no consumer is going to want and only
clueless publishers would insist on providing.” What is anyone
supposed to draw from that? Nor did it help to interpret this on
the level of vendor politics: implying that this extension came
to be just because IBM doesn’t want to play ball wasn’t the most
precise way to clarify its flaws. It wasn’t until David gave his
criticism that I saw any serious problem. 

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions


* James M Snell [EMAIL PROTECTED] [2006-05-02 22:25]:
 A. Pagaltzis wrote:
  I have to say that your architecture sounds rather
  heavyweight,
 
 Heavyweight?  It's Java. need I say more?

Hehe. I stopped just short of asking “is that in Java?” :-)

 Does your implementation properly handle the following
 (contrived) example:
 
 entry xml:base=http://example.org/foo/bar;
 ...
 link href=../comments.xml rel=replies /
 thr:replies href=http://EXAMPLE.org:80/foo/bar/../comments.xml; ... /
 ...
 /entry

You probably wanted a trailing slash on your base URI, else the
two hrefs are different.

 I know for a fact that Java's built-in comparison functions for
 the URI and URL classes do not.  I have to normalize the URI's
 after I resolve them before I can compare them.

Yeah, I need to do some extra work. I’m using Perl, whose URI
module does most of the work, but not all. Downcasing the host
name, removing explicit default ports, unescaping characters
which can be, and some scheme-specifics are all automatic, but
some things that should be (at least resolving `..` path segments
and escaping slashes in the query string) are not.

I should probably read the relevant RFCs and write test cases,
then file tickets… that stuff is bothersome.

 What's more, for each replies link, I need to iterate through
 all available thr:replies elements, resolve, normalize and
 compare each href.
 
 Pain.

Yeah. At the DOM level you could use XPath to avoid iterating… :-/

 It is possible that the spec could dictate that the thr:replies
 resolved href attribute MUST match the link's href attribute
 character-for-character, making the above example invalid.

That would be a solution. Would it be a burden on publishers?

  I can see that. Hrmf. There’s gotta be a better way…
 
 ;-) Yes, there is a better way, but y'all complained about it
 ;-)
 
 (sorry, couldn't resist)

Don’t be bitter now. :-)  That particularly choice does make
particular sense in your case; but that doesn’t mean it’s the
overall best.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Atom Rank Extensions




James Holderness wrote:
 
 Just looking at that example, it seems to me that an aggregator that
 implements Microsoft's simple list extensions would get a full-featured
 representation of that feed without having to know anything at all about
 feed rank and feed history. 
 

That's part of the point, actually.  The extensions can work
cooperatively with or independently of one another.

 So why bother with them?

The Feed history complete / element and SLE's
cf:treatAslist/cf:treatAs directly compete with one another, with
the exception that treatAs also defines that ordering of the entries is
important.

Feed Rank operates orthogonally to both.

 I'm sure you can come up with cases which couldn't be handled perfectly
 by SLE (which I'd be the first to admit is a pretty lousy spec), but
 it's out there now and it more or less works. Does feed rank really
 offer you so much more that it justifies a competing extension?
 

To understand where the value of Feed Rank comes in, consider adding
additional ranking dimensions to each entry.  For instance, an entry
might contain a position rank, an average five star review rank, a
average-review-from-my-friends rank, a critics ranking, a popularity
ranking (e.g. number of times the movie has been rented in the last
month), etc.

 entry
   ...
   r:rank label=Queue Position
   scheme=tag:example.org,2006:queue1/r:rank
   r:rank label=Average reviews (everyone)
   domain=tag:example.org,2006:reviews
   scheme=tag:example.org,2006:reviews/all3.5/r:rank
   r:rank label=Average reviews (friends)
   domain=tag:example.org,2006:reviews
   scheme=tag:example.org,2006:reviews/friends2.5/r:rank
   r:rank label=Average reviews (critics)
   domain=tag:example.org,2006:reviews
   scheme=tag:example.org,2006:reviews/critics3.0/r:rank
   r:rank label=Total rentals this week
   domain=tag:example.org,2006:rentals
   scheme=tag:example.org,2006:rentals/week5/r:rank
   r:rank label=Total rentals this month
   domain=tag:example.org,2006:rentals
   scheme=tag:example.org,2006:rentals/month50/r:rank
   r:rank label=Total rentals this year
   domain=tag:example.org,2006:rentals
   scheme=tag:example.org,2006:rentals/year500/r:rank
   r:rank label=Current queues (everyone)
   domain=tag:example.org,2006:queued
   scheme=tag:example.org,2006:queued/all40/r:rank
   r:rank label=Current queues (friends)
   domain=tag:example.org,2006:queued
   scheme=tag:example.org,2006:queued/friends2/r:rank
   ...
 /entry

In this sense, feed rank shares a closer relationship to atom:category
than it does to SLE.

With SLE, each sort key can appear only once within an entry.  In order
to implement the example above, you would have to create a new
namespaced extension element for each dimension you wish to sort on (not
necessarily a bad thing, but opens the door to having multiple
independent and non-interoperable vendor-specific namespaces that all
implement the same basic feature in slightly different ways). With Feed
Rank, we can have as many dimensions as we want, with a consistent
definition and processing model for each, without having to define a new
namespaced extension element for each dimension.

Further, SLE operates only on a single feed document.  Feed Rank is
capable of spanning multiple feed and/or entry documents, regardless of
whether they are pages in a single logical feed or are completely
independent of one another.  For instance, a school could offer one feed
for each class in which each entry represent a test grade for an
individual student.

  feed
titleClass 1/title
...
entry
  ...
  r:rank label=1
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades1.0/r:rank
/entry
entry
  ...
  r:rank label=1-
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades1.3/r:rank
/entry
  /feed

  feed
titleClass 2/title
...
entry
  ...
  r:rank label=4
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades4.0/r:rank
/entry
entry
  ...
  r:rank label=4-
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades4.3/r:rank
/entry
  /feed

  feed
titleClass 3/title
...
entry
  ...
  r:rank label=1
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades1.0/r:rank
/entry
entry
  ...
  r:rank label=2+
  domain=tag:example.org,2006:grades
  scheme=tag:example.org,2006:grades1.7/r:rank
/entry
  /feed

Using Feed Rank, you could choose to sort the student entries within a
single class feed (e.g. who are the top students in Class 1), or produce
a combined view spanning all three feeds (e.g. who are the top students
at the

Re: Atom Rank Extensions

2006-05-02 Thread David Powell



Tuesday, May 2, 2006, 9:12:56 PM, James Snell wrote:

 Does your implementation properly handle the following (contrived) example:

 entry xml:base=http://example.org/foo/bar;
 ...
 link href=../comments.xml rel=replies /
 thr:replies href=http://EXAMPLE.org:80/foo/bar/../comments.xml; ... /
 ...
 /entry

I don't think you should do URI normalisation. The ref is being used
as an identifier, you don't do protocol level normalisation on
namespace URIs or Atom ids why do it here? The draft should specify
character-by-character comparison of the resolved URI's.

[Er, I mean IRI. Everyone's using IRI datatypes, right?...]

-- 
Dave

Re: Atom Rank Extensions



On 5/2/06, James M Snell [EMAIL PROTECTED] wrote:


Again, however, Feed Rank is not intended to compete with the simple
list extensions.  They serve different purposes.  SLE defines a
processing model for individual feed documents whose entries represent a
sorted list; Feed Rank defines a way of assigning numeric rankings to
entries to facilitate sorting and grouping.


I find this explanation most unconvincing. Near as I can tell, this
spec serves an identical purpose, but it's much less flexible.

  In the Atom Syndication Format [RFC4287], the order of entries as
  presented in a feed is typically considered to be insignificant.
  This presents a challenge when the set of entries is intended to
  represent an ordered or ranked list.  This document specifies an
  extension...

Seems to me it's pretty darn similar.

--

Robert Sayre

Re: Atom Rank Extensions


Hi David,

* David Powell [EMAIL PROTECTED] [2006-05-03 01:15]:
 I don't think you should do URI normalisation. The ref is being
 used as an identifier, you don't do protocol level
 normalisation on namespace URIs or Atom ids why do it here?

That’s a good point; though there’s a slight difference as
namespace URIs must be absolute in the first place.

The `href` isn’t necessarily unique, now that I think about it,
if you play games with `xml:base`:

link href=comments.xml rel=replies /
link href=comments.xml rel=replies xml:base=./foo/ /

Of course, it’s entirely reasonable to declare this madness and
refuse to support it.

Maybe we need something like _A Plea for Sanity_ that Joe English
wrote about namespaces, for xml:base.

 The draft should specify character-by-character comparison of
 the resolved URI's.

Yeah, probably.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Feed thread -09 (was: Re: Atom Rank Extensions)


Ok, so how's this (not word-for-word as I would write it in the spec,
but you should get the idea)

The ref attribute MUST be an absolute URI that matches a the resolved
href URI of a replies link character-for-character (case sensitive)

In other words;

link rel=replies href=comments.xml
  xml:base=http://example.org/foo; /
thr:replies ref=http://example.org/comments.xml; ... /

- James

A. Pagaltzis wrote:
 Hi David,
 
 * David Powell [EMAIL PROTECTED] [2006-05-03 01:15]:
 I don't think you should do URI normalisation. The ref is being
 used as an identifier, you don't do protocol level
 normalisation on namespace URIs or Atom ids why do it here?
 
 That’s a good point; though there’s a slight difference as
 namespace URIs must be absolute in the first place.
 
 The `href` isn’t necessarily unique, now that I think about it,
 if you play games with `xml:base`:
 
 link href=comments.xml rel=replies /
 link href=comments.xml rel=replies xml:base=./foo/ /
 
 Of course, it’s entirely reasonable to declare this madness and
 refuse to support it.
 
 Maybe we need something like _A Plea for Sanity_ that Joe English
 wrote about namespaces, for xml:base.
 
 The draft should specify character-by-character comparison of
 the resolved URI's.
 
 Yeah, probably.
 
 Regards,

Re: Tools that make use of previous/next/first/last links?

2006-05-02 Thread Mark Nottingham




On 2006/05/01, at 12:55 AM, James M Snell wrote:


Eric Scheid wrote:
I thought OpenSearch results are not sorted by chronological age  
at all, but
instead by relevance? Using next with OpenSearch makes sense in  
that

context. Using previous for stepping back thru time in a data store
arranged chronologically makes sense.


What Eric said.


As it stands now, a single feed
cannot implement APP, OpenSearch AND Feed History.


Please describe the scenario where you'd want that to happen -- show  
the feed.



--
Mark Nottingham http://www.mnot.net/

Re: Tools that make use of previous/next/first/last links?

2006-05-02 Thread Mark Nottingham



Peter,

Can you expand upon being more precise about exactly what is needed?


On 2006/05/01, at 3:16 AM, Peter Robinson wrote:


Mark Nottingham [EMAIL PROTECTED] wrote:

One thing I did notice -- you're using URLs like this for your  
archives:

   http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2amp;count=10

Are they really permanent? If they're relative to the current state
of the feed (i.e., the above URI means give me the ten latest
entries), you can get into some inconsistent states; e.g., if
somebody adds/deletes an entry between when the client fetches the
different archives. Also, if a client doesn't visit for a long time,
it will see
   http://journals.aol.com/panzerjohn/abstractioneer/atom.xml?
page=2amp;count=10
and assume it already has all of the entries in it, because it's
fetched that URI before.


This is the biggest issue I have with the history spec as written.  I
have urls like that, which aren't 'archive documents' as defined.   
That
means I can't implement the history spec even though I have  
conventional

chronologically ordered feeds with link rel=prev/next elements where
old entries are available.

I believe that by being more precise about exactly what is needed  
by the

client to implement feed history usefully you can significantly relax
the requirements.  I believe the algorithm can be written so that
clients can use history with a feed like mine.

Regards,

Peter





--
Mark Nottingham http://www.mnot.net/

Weekly Posting Summary



   Messages   |  Bytes| Who
+--++--+
29.09% |   16 | 36.32% |83142 | [EMAIL PROTECTED]
16.36% |9 | 14.13% |32346 | [EMAIL PROTECTED]
12.73% |7 | 11.57% |26492 | [EMAIL PROTECTED]
 7.27% |4 |  6.01% |13765 | [EMAIL PROTECTED]
 7.27% |4 |  5.47% |12527 | [EMAIL PROTECTED]
 5.45% |3 |  5.84% |13377 | [EMAIL PROTECTED]
 3.64% |2 |  6.26% |14339 | [EMAIL PROTECTED]
 3.64% |2 |  2.87% | 6578 | [EMAIL PROTECTED]
 3.64% |2 |  2.87% | 6563 | [EMAIL PROTECTED]
 3.64% |2 |  2.46% | 5632 | [EMAIL PROTECTED]
 1.82% |1 |  1.89% | 4331 | [EMAIL PROTECTED]
 1.82% |1 |  1.53% | 3512 | [EMAIL PROTECTED]
 1.82% |1 |  1.42% | 3246 | [EMAIL PROTECTED]
 1.82% |1 |  1.34% | 3070 | [EMAIL PROTECTED]
+--++--+
100.00% |   55 |100.00% |   228920 | Total


--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: Atom Rank Extensions


* Robert Sayre [EMAIL PROTECTED] [2006-05-03 03:15]:
  You know, stuffing an idea because of who proposed it.
 
 No, not just because of who proposed it, but also because of
 how.
 
 Sorry Aristotle, you're not qualified to make that statement.
 I've proposed things every which way, so I know the form
 doesn't matter.

Indeed, I’ve only been a witness to the discussion in a few
venues, so I can’t pass judgement about the big picture. I have
to take your word for it.

However, with regard to the part of the picture in which I did
participate, I will go on record to say that you almost never
made it easy for me to consider your position on an issue on
which I was trying to make up my mind when held a strong opinion
about it. And that’s not for lack of willingness on my part, nor
is it because your positions have been unreasonable. I often
wished you’d argue your case better.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Tools that make use of previous/next/first/last links?