Re: Current and permalink link rel values

[Antone Roundy]

On Feb 23, 2007, at 7:16 AM, Elliotte Harold wrote:
I'd like to add multiple links to my feed for both the current  
version of the story and the permalink. E.g.

...

http://www.cafeconleche.org/#February_22_2007_30633"/>
http://www.cafeconleche.org/oldnews/ 
news2007February22.html#February_22_2007_30633"/>


Both of those would probably be best described as "alternate" links.   
The second one in particular is what "alternate" was intended to be  
used for.  However, RFC 4287 contains the following:


   o  atom:entry elements MUST NOT contain more than one atom:link
  element with a rel attribute value of "alternate" that has the
  same combination of type and hreflang attribute values.

So you couldn't keep both as "alternate" links.  In my opinion, you  
should use the second one (the longer lasting one) only, and omit the  
first (which is going to become invalid as soon as the entry falls  
off the page anyway -- anyone who used it to get to your page and  
bookmarked it, and anyone who follows it from a cached copy of your  
feed isn't going to be able to find the entry without a lot of  
needless digging through your archives). You should have a link to  
http://www.cafeconleche.org/ at the feed level.  While that won't  
link directly to that entry, it'll get people to it as long as it's  
on that page.

Re: Query re: support of Media RSS extensions inside Atom feeds

[Antone Roundy]

On Feb 9, 2007, at 9:23 PM, John Panzer wrote:
Does anyone know of any issues with placing Yahoo! Media RSS  
extensions (which seem to fit the requirments for Atom extensions  
to me) inside an Atom feed?  Secondarily, do feed readers in  
general recognize MRSS inside either Atom or RSS?  Looking for  
field experience/implementor intentions here.


CaRP partially supports Media RSS in RSS (it doesn't directly support  
Atom at all, and Grouper, the companion script that converts Atom to  
RSS for it doesn't yet have Media RSS support, though I may add it in  
the next update).  It only looks at elements pointing to images  
(@type="image/*") and their types, heights and widths.  I added this  
in response to user requests--primarily, I believe, for use with  
Flickr feeds.


Antone

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Antone Roundy]

I'm not subscribed to the APP mailing list, so hopefully this isn't  
all redundant:


On 12/15/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
A model where servers aren't required to keep such information  
won't, in

practice, allow that kind of extension. If clients can't rely on their
markup getting stored, then clients can't extend Atom unilaterally  
using XML

markup.


There are two different issues here, which I think has been  
mentioned, but which might bear being clearly stated:


1) Do servers have to keep all extension data?

2) Can a server accept an entry while discarding some or all  
extension data, or do they have to reject the entry and return an  
error code?


I think the answer to the first question is clearly no--servers  
shouldn't be required to store all arbitrary data that is sent to  
them.  So the questions are:


1) Which hurts more--data loss or rejected entries?

2) Is there any way to reduce that pain?

The pain of data loss is obvious--the data is lost.  The pain of  
rejected entries is having to fix and repost them or decide not to  
try again.


In either case, it might be useful to be able to query the server  
somehow to find out what it will and won't preserve.  If data is  
discarded, you can figure that out after the fact by loading the  
resulting entry and checking whether the data is all there, but one  
might prefer to know ahead of time if something is going to be lost  
in order to be able to decide whether to post it or not.  If the  
entry is just going to be rejected, unless there's a way for the  
server to communicate exactly which data it had issues with, fixing  
the data to make it acceptable could be extremely difficult ("Hmm,  
I'll leave this data out and try again...nope, still rejected. I'll  
put that back in and leave this out...nope. I'll take both  
out...nope. I'll put both back in and take yet another piece of data  
out...").


So, how might a client query a server to see what it will preserve?   
A few possibilities:


1) Have some way to request some sort of description of what will and  
won't be preserved and what might be altered.  I don't know how one  
would go about responding to such an inquiry except to basically send  
back a list of what will be preserved, including some way to say  
"I'll preserve unknown attributes here", "I'll preserve unknown child  
elements (and their children) here", "I'll store up to 32767 bytes  
here", etc.  If there is any known extension markup that a server  
wants to explicitly state that it won't preserve, there may need to  
be a way to do that too.


2) Have a way to do a "test post", where one posts the data one is  
considering posting (or something structurally identical), but says  
"don't store this--just tell me what you WOULD store".  The response  
could include what would be returned if one were to load the data  
after it being stored, or it could be some sort of list of anything  
that would be discarded or altered.


3) (I get the impression this could be done without requiring  
changes--is this the sort of process that has already been  
selected?)  Post the data as a draft, reload it to see if it's all  
still there.  If so, or if what has been preserved is acceptable,  
change it's status to "published" or whatever it's called.  If not  
delete it and give up or take whatever other action is appropriate.



My impression is that data loss would be less painful and more easily  
dealt with than rejection of entries that won't be completely preserved.


...but I haven't followed the discussion, so what do I know.

Re: PaceEntryMediatype

[Antone Roundy]

On Dec 6, 2006, at 4:26 PM, Jan Algermissen wrote:
Most feed readers knows how to handle feeds, but have no idea how  
to handle entries.


So they should be fixed, should they not?


If the purpose of a feed reader is to subscribe to feeds and bring  
new and updated entries to the user's attention, then if they don't  
also handle the monitoring of single entry documents (interesting to  
some people in some cases, but I doubt interesting to most people),  
that's not necessarily something that needs fixing.



They seem to only have implemented half a media type.


...or they've implemented all of what should be covered by one media  
type.

Re: PaceEntryMediatype

[Antone Roundy]

On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
Following a link is not the same thing as subscribing to something.  
The act of subscribing is a local activity performed by the user  
agent. What you do when you follow the link to a feed is a GET.  
Your agent then decides if subscribing to that resource is a good  
idea. To make that decision, the agent has to look at the  
representation and the it is insignificant overhead to see if the  
thing returnes  or .


...

Maybe I want to monitor a single media resource; an Atom media  
entry would be an ideal thing to do so (I'd rather look at the meta  
data than at the media resource upon each poll).


 I'd say: stick with the one media type that is currently there -  
there is no problem, just misconception about what it means to  
subscribe.


A few reasons why a user agent might want to be able to tell the  
difference between a link to a feed and a link to an entry beforehand  
is in order to:


1) be able to ignore the link to the entry (ie. not present it to the  
user) if the user agent doesn't handle entry documents (rather than  
presenting it as a "subscribe" link, only to have to say "sorry, it's  
not a feed" after the user tries to subscribe).


2) be able to say "subscribe" to links to feeds, and "monitor" links  
to entries (the user may not be interested in monitoring a single  
entry for changes--if they can't tell that that's what the link is  
for, they may end up needlessly doing so but think that they've added  
another feed to their subscription list).

Re: PaceEntryMediatype

[Antone Roundy]

On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:

On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
All a media type tells you (non-authoritatively too) is the spec you
need to interpret the document at the other end of the link.  That has
very little to do with the reasons that you might want to follow the
link, subscribe to it, etc..  Which is why you need a mechanism
independent from the media type.  Like link types.


Now that this has sunk in, it makes a lot of sense--the @rel value  
says "you can subscribe to that", "that is an alternative  
representation of this", "that is where you'd go to edit this", and  
so on.  The media type helps the user agent figure out whether it has  
the capability to do those things.  For example, a feed reader that  
only handles RSS could ignore subscription links to resources of type  
"application/atom+xml" (ie. not present the subscription option to  
the user).  The "subscribe to hAtom feed" case where @type is "text/ 
html" might be a little difficult to make a decision on, because  
there's no indication of what microformat is being used by the  
"feed" (or even if there's a microformat in use at all--maybe it  
really is just an HTML page, and "subscribing" to it just means  
"watch for changes to the entire document").  But in the case of bare  
syndication formats, things should be clear enough.


So if it really is possible to do option 5 (new media type for entry  
documents, and @rel values to solve the rest of the issues), and do  
it cleanly, then that'd be my first choice.  If that's doomed (due to  
a need to be backwards compatible with existing practice) to be a  
mess of ambiguities and counter-intuitivities (eg. "alternate" means  
"subscribe" when combined with a syndication type, except when it  
might really mean "alternate" because it points to a feed archive  
document, but anything with "feed" in it always means "subscribe"...)  
then oh my.


One problem that I hadn't really thought clearly about till right now  
is that understanding the nature of the think linked TO may require  
some understanding of the nature of the thing linked FROM.  For  
example, an "alternate" link from a typical blog homepage to its feed  
really does point to the same thing in an alternative format.  Both  
are live documents in which new data gets added to the top, and old  
data drops off the bottom.  But if you don't know that the webpage is  
a live document, you wouldn't know whether the link pointed to a  
static or live document.  "alternate" is perfectly accurate, but it's  
not helpful enough.  "subscribe" would be much more explicit.


Which raises the question of how to point to a static alternative  
representation of the data currently found in the document.   
"alternate" WOULD be a good word to use for that except that it's  
already being used to point to live feeds.  An option that would  
almost surely cause confusion would be to use "alternative" for  
static alternative representations.  The meaning of "static" wouldn't  
exactly be intuitively clear.  Maybe something more long-winded like  
(oh no! hyphenation!) "static-alternate" would do.  Or would "static  
alternate" (and "alternate static" and "static foo alternate",etc.,  
or perhaps "archive alternate", etc.) be better?  For backwards  
compatibility (at least with UAs that don't expect only one value in  
@rel), "subscribe alternate" (and "alternate subscribe", etc.) could  
be used rather than simply "subscribe".


BTW, am I remembering correctly that "feed" is being promoted for use  
the way I'm considering "subscribe" above?  If it's not already in  
use, I'd thinK "subscribe" would be much better than "feed", because  
"feed" could as easily mean "archive feed" as "subscription feed"-- 
it's just not explicit enough.


But perhaps this discussion all belongs in a different venue anyway...


But before I end, what about the question of a different media type  
for entry documents?  For the APP accept element issue, it sounds  
like maybe they do.  But for autodiscovery, maybe they don't.   
Perhaps neither @type nor @rel is the place to distinguish, for  
example, between the edit links for entries, their parent feeds,  
their per-entry comment feeds, monolithic comment feeds, etc.  (A  
media type for entry documents would only help with one of those).   
Perhaps that is the domain of @title (title="Edit this entry", etc.)   
Do UAs really need to know the difference, or do only the users need  
to know?  Would making that information machine readable be worth the  
pain involved (rel="edit monolithic parent comments"???)



Okay, that's all I can take for now.

Re: PaceEntryMediatype

[Antone Roundy]

Summary of thoughts and questions:

*** Problems with the status quo ***

A) Consumers don't have enough information (without retrieving the  
remote resource) to determine whether to treat a link to an Atom  
document as a link to a live feed, a feed archive, or an entry.  (Is  
it appropriate to poll the link repeatedly?  How should information  
about the link be presented to the user?)


B) APP servers can't communicate whether they will accept feed  
documents or only entry documents.



*** Possible solutions ***

1) Add a type parameter to the existing media type:

+ With the exception of a few details, the documents are all exactly  
the same format (does it contain a feed element, or does it start at  
the entry element, is it a "live" feed document or an archive, etc.),  
so a single media type makes the most sense (definitely for live  
feeds vs. archives, less certainly for feeds vs. entries).


- Some existing applications will ignore the parameter and may handle  
links to non-live-feeds inappropriately


- Some existing applications may not recognize application/atom 
+xml;type=feed as something appropriate to handle the same way they  
handle application/atom+xml now.


? I haven't been following development of the APP, so forgive my  
ignorance, but can parameters be included in the accept element?



2) Create (a) new media type(s) (whether like application/atomentry 
+xml or application/atom.entry+xml):


+ Applications that currently treat all cases of application/atom+xml  
the same would ignore non-feed links until they were updated to do  
something appropriate with the new media type.


- Differentiating between live feeds and archives by media type seems  
really wrong since their formats are identical.  This isn't as big a  
negative for entry documents, but it still seems suboptimal to me.


- If a media type were created for archive documents, would APP  
accept including application/atom+xml imply acceptance of archive  
documents too?  Neither yes nor no feels like a satisfying answer.



3) Use @rel values to differentiate:

- That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why make it  
worse?


+ That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why not work  
on all these messy problems in the same place?


- That wouldn't help with the APP accept issue.


4) Create a new media type for entry documents, and add a parameter  
to application/atom+xml to differentiate between live and archive  
feeds (and for any other documents that have the identical format,  
but should be handled differently in significant cases).


- Doesn't prevent existing apps that ignore the parameter from  
polling archive documents.


+ Does solve the rest of the problems without the negatives of #2 above.


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 #4 first, and perhaps #5 second, but I'd have  
to think about #5 more first.


Antone

Re: PaceEntryMediatype

[Antone Roundy]

On Nov 30, 2006, at 2:13 AM, Jan Algermissen wrote:

On Nov 29, 2006, at 7:22 PM, James M Snell wrote:

One such problem occurs in atom:link and atom:content elements.
Specifically:

  
  

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.


And what is the problem with that?


Here's one problem: in this and the autodiscovery case, the UA can't  
tell without fetching the remote resource whether it's appropriate to  
display a "subscribe" link.  In fact, even if the remote resource is  
a feed, it may not be appropriate to subscribe to, because it may be  
an archive document rather than the live end of a feed.


Of the options presented, I'd favor adding a type parameter to  
application/atom+xml.  In addition to "feed" and "entry", we may want  
"archive".

Re: atom license extension (Re: [cc-tab] *important* heads up)

[Antone Roundy]

On Sep 6, 2006, at 7:51 AM, James M Snell wrote:
The problem with specifying a per-feed default license is that  
there is
currently no way of explicitly indicating that an entry does not  
have a

license or that any particular entry should not inherit the default
feed-level license.


With respect to atom:rights (from RFC 4287 section 4.2.10):

   If an atom:entry element does not contain an atom:rights element,
   then the atom:rights element of the containing atom:feed element, if
   present, is considered to apply to the entry.

Thus, at the entry level,  would (certainly ought to!)  
detach a feed level atom:rights element from the entry without  
replacing it with anything.  With sure how you'd do the same thing.  Is it possible to specify a null  
URI?   points to the in-scope xml:base  
URI, right?  Perhaps the specification could define a "null license"  
URI.


With respect to the issue of aggregate feeds, I had thought that the  
existence of an atom:source element at the entry level blocked any  
"inheritance" of the feed metadata, but looking at RFC 4287, I don't  
see that explicitly stated.  Certainly if atom:source contains  
atom:rights, then that element overrides the feed-level atom:rights  
of the aggregate feed, but if neither atom:source nor atom:entry  
contains an atom:rights element, what then?  Perhaps in that case,  
the aggregator should add  as a child of atom:source  
(I'd think that preferable to adding it as a child of atom:entry).


On Sep 6, 2006, at 4:38 AM, Thomas Roessler wrote:

So, here's the proposal:

- Use  for entry licenses -- either on the feed
  level, setting a default analogous to what atom:rights does, or on
  the element level.

- Introduce  (or whatever else you
  find suitable) for licenses about the collection, to be used only
  on the feed level.


If there's a @rel="license" at the feed level, but no rel="collection- 
license", does the @rel="license" also become a "collection- 
license"?  (People who don't read the spec would probably think so).   
If there is no license for the collection, but one wishes to specify  
a default license for the entries, a "null license" would once again  
be useful.


Antone

Re: clarification: "escaped"

[Antone Roundy]

On Jul 26, 2006, at 3:19 AM, Bill de hÓra wrote:

A. Pagaltzis wrote:

* Robert Sayre <[EMAIL PROTECTED]> [2006-07-26 01:45]:

On 7/25/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:

And I didn't know whether Atom code could get away with
escaping < and &.

 hmm

that is an XML fatal error, no doubt, as the ampersand before
"nbsp" must be escaped.

But he did say “escaping < and &”, so it would be. I’m not sure
what Bill’s question even is.


What do I escape, so I know what to unescape?


The point is that after your XML parser has unescaped the content of  
the element, it should be suitable for handling as HTML.  Escape  
whatever you have to ensure that the consumer gets HTML from their  
XML parser.  Converting & to & and < to < is sufficient  
(assuming that you've started with HTML--if you've started with plain  
text, then you need to double escape, but in that case, you should be  
using type="text" anyway to save yourself the trouble).  You could  
also convert > to >, " to ", ' to ' and any other  
characters to numeric character references.  Or you put the whole  
thing in a CDATA block.