Re: Autodiscovery Draft

[Eric Scheid]

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
> that would be.  I do think that collection autodisco is important.)

please remember that there may be multiple collections collated into one
feed ... and that various members of one collection may be represented in
many different feeds.

it's not 1:1.

e.

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

[Eric Scheid]

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 to
>> annotate my entries automatically with what music I was
>> listening to (track name, album and artist in XML elements)
>> while I wrote a blog posting, I thought AtomFu should just
>> store that as XML markup in the entry.
> 
> That is, IMO, a misconception about Atom ­ one that is frequently
> seen. We just had a similar discussion tonight in #atom on the
> Freenode IRC network. The track name, album and artist are data;
> they should be part of the payload of an entry, not part of its
> envelope. In practice, that means you use either microformats or
> a more structured format than HTML. Extending the Atom envelope
> is a strategy of last resort.

wha?

What music Lisa is listening to when she wrote a blog posting is meta data,
not content, unless of course she's writing a blog posting *about* that
particular bit of music. The music is contextual meta data, along the same
vein as geo location of circumstance, the atom:generator involved, and even
the atom:published date/time.

Since when are we calling atom entries "envelopes"?

e.

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

[Eric Scheid]

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 exactly, but I did raise the possibility of a client passing in XML
whose only purpose is for the benefit of other clients. Things like
editorial comments and such. These would have been shepherded in the
app:control element, and there was a great deal of discussion about the
contents of app:control not being "published" (whatever that meant).

It got hairy, and there wasn't much support for the idea.

e.

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

[Eric Scheid]

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 this assertion? or is this another case of
"the server is in charge and can accept or change whatever it wants"?

e.

Re: Atom Entry docs

[Eric Scheid]

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 ;type=entry be used. (Note: Just
> because ;type=entry is used DOES NOT imply that ;type=feed must also be
> used) 

+1

Re: Atom Entry Documents

[Eric Scheid]

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 the target Atom document.  Feed vs. entry is just one syntax
> variant of an Atom document, others of UA interest might be "this is an Atom
> document containing OpenSearch results" or "this is an Atom Document that
> describes media using Media RSS extensions".

I'm not so sure. I see the difference between the two being "one" vs "many",
and nothing more. What you want could however be accommodated by additional
parameters..

> I'm not sure that treating each syntax variant as a unique MIME type is a
> scalable approach for the long haul.  One specific issue is that you will also
> have to deal with combinations (ex "this Atom document is a feed that contains
> OpenSearch results listing Media RSS entries").

application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS

(or syntax to that effect)

e.

Re: PaceEntryMediatype

[Eric Scheid]

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 pragmatic solution would be to go with "application/atom.entry+xml"
... if WHATWG don't update their spec, we're safe; if anyone has implemented
per the current draft WHATWG spec, we're safe; if any implementations use
naïve string matching, we're safe. The only danger is if someone has
implemented APP per the moving target which is Draft-[n++] ... they should
revise their test implementations as the draft updates, and certainly update
once it reaches RFC status, so no sympathies there.

e.

Re: PaceEntryMediatype

[Eric Scheid]

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
>> occur once per element, and not twice or more .. eg. > /> ?
>> 
> 
> Ok, you lost me on these last two. I'm not sure what you're getting at.

It's just the cardinality question in a different context. Argument by
analogy.

e.

Re: PaceEntryMediatype

[Eric Scheid]

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. An
editor application, for example, would know how to handle collection feeds
and entry documents, but would reasonably not be expected to know what to do
if it retrieved a feed document when attempting to edit a specific entry
(especially if it PUT/POSTed the entry as an entry document in the first
place).

Similarly, if an atom:entry element was wrapped inside some other unexpected
XML document (eg. RSS 1.0) ... should applications be prepared to cope with
that?
e.

Re: PaceEntryMediatype

[Eric Scheid]

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 Feed documents.  The majority of applications that most
> frequently handle Atom Feed Documents have no idea how to deal with Atom
> Entry Documents and I would wager that most applications that understand
> how to process Atom Entry Documents and Atom Feed Documents typically
> don't fall into the same category as most feed readers.

If an agent found an entry document, should it assume that it's a feed with
one entry (so far) and allocate resources accordingly (ie. allow for
cardinality of n++)?

If an agent found an entry document, and then later returned to find a feed
containing multiple entries, would it consider that a problem?

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
occur once per element, and not twice or more .. eg.  ?

e.

Re: PaceEntryMediatype

[Eric Scheid]

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

Starting from scratch, idealised, I'd want different media types (or params)
for entry documents and feed documents, and link type which clearly
indicates "this is for subscription", as distinct from "this is an alternate
representation", "this is an archive", etc.

Using the two mechanisms together allows combinations such as "here is a
feed you can subscribe to of the comments for this entry" and "here is a
feed document listing related resources, but since it won't likely be
updated don't bother subscribing".

I'd like to be able to use a lot of the link types we currently use for html
(directory, help, toc, related, next, etc) to refer to resources which
happen to be serialised in the atom feed document format, and feel safe in
knowing they won't be automagically treated as being subscription feeds.

e.

Re: PaceEntryMediatype

[Eric Scheid]

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 when linking to feed documents, some when linking to entry
documents.

e.

Re: PaceResurrectAutodiscovery

[Eric Scheid]

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 former is the syndication feed to
which one would reasonably subscribe to for delivery of more content like
you're looking at, and the latter is simply an alternate representation of
the current content (in this case being an archive page for October 2006),
and subscribing to it would be foolish.

Also, how do we have syndication feeds in different representation formats
(eg. RSS), or are you proposing the ";type=feed" gets appended to all the
various media types as needed?

> "The feed keyword indicates that the referenced document is a
> syndication feed. If the alternate link type is also specified, then
> the feed is specifically the feed for the current document;
> otherwise, the feed is just a syndication feed, not necessarily
> associated with a particular Web page."

There's a third case they don't mention here, which is if 'alternate' is
used but 'feed' is not also specified ... in which case it's not a "feed" in
the sense of a source of continuing updates, but more like a static resource
(subject to the usual bit rot and tweaky updates).

The three cases are:

@rel="feed"
@rel="alternate feed"
@rel="alternate"

Would be nice if there was an RFC we could point at which clarified what is
meant by each. Would go a long way towards overcoming deployment inertia.

e.

Re: PaceResurrectAutodiscovery

[Eric Scheid]

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 trumps what's technically correct.

That's like saying candles and oil lamps trump Mr. Edison's delightful
invention. Sure, when he came up with the idea there were not many adopters,
but just look around today.

Maybe a robust de facto standard will arise. Or maybe a hodge-podge of
incompatible almost-solutions get deployed. How many varieties of (e.g.) RSS
are there again?

We're in a good position, in this WG, to suggest a future standard. We've
delved deeply into the intricacies, we've examined a wide range of use
cases.

Speaking of which ... there's another use case to consider. Since Atom has
promoted interest in using feed documents in an archival manner, it is
entirely reasonable to use @rel="alternate" to point to an archive feed
document which contains the *same* content as the referring page, as opposed
to referring to a feed document which has the "most recent" additions from
the same source as where the contents of the current page came from. (what a
mouthful!)

The archival feed document is truly the "alternate" for the html page
"entries of october 2006", while the subscription feed document for the same
source (and containing entries mostly from November 2006) would be the
"feed" document.

Sure, when it comes to turning back the tide to *deprecate* the use of
@rel=alternate for subscription feeds in lieu of archival feed documents,
I'm fully in agreement that current practice trumps that idea.

The other idea though of using "feed" to indicate the resource one would
subscribe to so as to be _fed_ more of the same content ... that doesn't
conflict with current practice and we can lay the ground work for future
adoption.

e.

Re: PaceResurrectAutodiscovery

[Eric Scheid]

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 draft at all prior to resurrection. We
> can see whether we want any new language in there once we have it
> back in the process.

agree, although this is just a matter of process. So, +1 to resurrect, -1 to
"and submit for consideration as a Proposed Standard."

> +0 to including *additional* provisions in the draft before
> submitting it for approval, because I do agree it¹s incomplete.

agree.

e.

Re: AD Evaluation -- extensions

[Eric Scheid]

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 so.  That makes it hard
> for clients to extend AtomPub's syntax in ways that other clients will
> understand but servers don't care about.  Consider the consequences: when some
> enterprising client developer decides to do something cool and useful and
> encounters servers that don't store their metadata in the obvious place, the
> client developer is going to quickly work around that by storing in some
> unobvious place.  For example in HTML comments in the atom entry content, or
> microformats, etc.  Is that all cool?  

This issue also has implications on what extensions are passed through to
the published feed ... a client might insert some extension metadata they
want published (eg. geo-coordinates), and a client might insert some
extension metadata they only want visible within the collection feed (eg.
editor workflow comments) ... with the understanding also that if the server
actually understands a particular extension it might result in extensions
being added/modified outside of the bucket (eg.  resulting in lots of  elements being added)

We did at one time discuss providing a bucket container specifically for the
latter, with the assumption that extensions outside the bucket are data
elements meant for publication. Having a bucket container would make life
simpler for server implementations -- just store everything as an xml blob,
the same as they do for atom:[EMAIL PROTECTED]

Lisa, would that help?

e.

Re: Atom and bidi

[Eric Scheid]

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-text

I know the difference between @xml:lang and @hreflang ... so which is @dir
analogous to?

e.

Re: Atom and bidi

[Eric Scheid]

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:lang doesn't go to a child (embedded) document.

> The  language specified by  xml:lang applies to the element where
> it is specified  (including the values of its attributes), and to all
> elements in its content unless overridden with  another instance of
> xml:lang.

what happens here?

 .. yadda .. 

e.

Re: Atom and bidi

[Eric Scheid]

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 by contained elements (similar to how xml:lang
and xml:base is)?

what happens with  ?

e.

Re: Atom Syndication Format To Draft Standard?

[Eric Scheid]

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.

Re: WG Last Call for draft-ietf-atompub-protocol

[Eric Scheid]

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 instantly into a rat-hole.
> 
> Conclusion.  PaceAppEdited is accepted, in part. The second part of
> the proposal, defining the app:edited element, is ACCEPTED.  The
> first part, imposing a requirement on the sort order of collections,
> clearly does not have consensus support.

There also seems to be universal support for the notion that collection
feeds could be sorted by something other than what's currently in the spec.
The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be sorted by
anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

The entries in the returned Atom Feed MUST be ordered by their
   "atom:updated" property, with the most recently updated entries
coming first in the document order. Clients SHOULD be constructed
in consideration of the fact that changes which do not alter the
atom:updated value of an entry will not affect the position of
the entry in a Collection.

We need to either strike that entire paragraph, or at the very least make
that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.

atom:updated - not now() values?

[Eric Scheid]

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 quickly enter it into the
CMS and set the atom:updated value to Monday 4 PM.

e.

Re: Language Negotiation

[Eric Scheid]

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 does not match the
> "accepted languages".
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7

so, do not return the requested language alternate?

e.

Re: Language Negotiation

[Eric Scheid]

>> 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
 document), asking for a different language?

e.

Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt)

[Eric Scheid]

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 xml being nested.

in other words, what is the lang of the atom:content below:


HTTP 200 OK
Content-Language: ch
...




...

...

...


e.

Re: Copyright, licensing, and feeds

[Eric Scheid]

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 aggregators that are not aware of that inheritance.

e.

Re: Copyright, licensing, and feeds

[Eric Scheid]

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 (license ???)
>  entry (license A) from feed X
>  entry (license B) from feed Y
>  entry (license B) from feed Y
>  entry (license A) from feed X
>  entry (license C) from feed Z

either no license element at the the feed level (since every entry has their
own license), or maybe a license that refers to the collection (eg. you
could expose a license for your Top 10 List without necessarily claiming any
license for the 10 items in the list).

Interesting to think what different licenses might entail though: you could
deny breaking up your feed by no-deriv (which would only work to the limit
of fair use, ie. I could still cherry pick the occasional entry, although
the entry's license might still stop me). If someone were to publish their
Top 10 List, you could disallow someone re-aggregating it as a Top 5 List,
say. 

e.

Re: Feed Thread in Last Call

[Eric Scheid]

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.

Re: Feed Thread in Last Call

[Eric Scheid]

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 detect if there has been a
significant change ... everything else is just meta data.

e.

Re: Feed Thread in Last Call

[Eric Scheid]

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.

Re: Feed Thread in Last Call

[Eric Scheid]

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.

:-)

Re: Feed Thread in Last Call

[Eric Scheid]

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 just pointing at different representations of the same set of
> responses.

would this mean this is possible:




...


e.

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

[Eric Scheid]

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 of entries that match
> some criteria (opensearch). No matter what the various link types point
> to, there needs to be consistency. As it stands now, a single feed
> cannot implement APP, OpenSearch AND Feed History.

I just reviewed the relevant example in the APP spec and it's worrisome.
Reading between the lines it suggests that the subscription uri is
"http://example.org/entries/go";, with the rest of the collection available
via rel="next" through to "http://example.org/entries/10";.

The worrisome thing is that once that collection gains another 10 entries,
then the resource "http://example.org/entries/11"; will now contain the
entries which were previously contained by resource
"http://example.org/entries/10";. Every page of the collection needs to be
updated and have the entries shuffled along.

A simplified example:

/entries/go contains entries Q,R,S,T
/entries/2 contains entries M,N,O,P
/entries/3 contains entries I,J,K,L
/entries/4 contains entries E,F,G,H
/entries/5 contains entries A,B,C,D

which then gets another 4 entries added (ie. U,V,W,X) and the collection now
looks like this:

/entries/go contains entries U,V,W,X
/entries/1 contains entries Q,R,S,T
/entries/2 contains entries M,N,O,P
/entries/3 contains entries I,J,K,L
/entries/4 contains entries E,F,G,H
/entries/5 contains entries A,B,C,D

This is just smells bad in so many ways. Pity the blog package that
publishes static files and will have to rebuild every collection page. Pity
the poor server that gets asked if /entries/3 has been modified and if so
hand it over. Pity the google bot that does all that asking.


Of course, this sentence doesn't parse into English real well either:

"next" and "prev" link elements reference the
preceding and subsequent feed documents in the set.

ie. "next" references the *preceding* feed document, and "prev" references
the *subsequent* feed document. It doesn't even make sense when read Down
Under ;-)

e.

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

[Eric Scheid]

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 link in both OpenSearch, APP and Gdata.

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.

I'm not familiar with how Gdata arranges it's data, but briefly scanning the
API docs it's modelled on OpenSearch, and furthermore it says "Result
ordering is up to the implementation" ... thus I would think it would be
right for it to use 'next' to get the next page, but wrong to assume that
this would imply stepping backwards chronologically.

e.

Re: Feed Thread Draft Updated

[Eric Scheid]

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"?

  
  5

You just know there'll be a few idiots that will try that on.

e.

Re: Feed Thread Draft Updated

[Eric Scheid]

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, Atom/RSS, GRDDL)

as I understand it, dereferencing the 'edit' link returns a representation
of the entry which is suitable for editing (ie. it contains all the bits
needed).

as to the other link types in html ... I hope we've learned something from
that experience since then.

e.

Re: Feed Thread Draft Updated

[Eric Scheid]

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 thr:when into a namespace (namespaced
> attributes confuse people).

atom:link beats thr:replies on the basis that I don't need to understand
what "replies" are to discover that there is a link from this thing to that
thing.

atom processors know what atom:link is, but it wouldn't know what to do with
this:

 

e.

Re: xml:base in your Atom feed

[Eric Scheid]

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. Having to click through links
> to see if they are valid can get a bit tiresome when you've trying to
> evaluate 16 tests on 20 different aggregators.

one way would be to use  instead of  links, with each test image
being specific to the test ... that way all one needs to do is read the feed
and check to see if the text in the image corresponds to the text in the
entry headline. Especially easy if the tests were numbered.

e.

Re: Does xml:base apply to type="html" content?

[Eric Scheid]

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 document referenced by an associated link
>> element, and therefore no guarentee that the xml:base of the atom
>> feed is going to be anywhere even close to accurate.

I'm doing something similar right now, scraping some website that doesn't
provide feeds for what I want. I check the html of the page I scraped and if
they have a  I use that, else I use the URL I used to fetch the page.

The tag soup I extract for each entry contains relative references. I really
don't want to go fixing that tag soup so I just stick that base url into
xml:base for each entry (and not just at the top of the feed, because I'm
scraping paginated results).

e.

Re: atom:name ... text or html?

[Eric Scheid]

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 work reliably.

I figured as much. Oh well, now to track down a list of html entities and
their corresponding unicodes ...

e.

Re: atom:name ... text or html?

[Eric Scheid]

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 defined, meaning
most interesting entities from html can't exist in XML ... unless maybe they
are wrapped like in CDATA block like above?

I'm getting the data by scraping an html page, so I'm expecting it to be
acceptable html code, including html entities.

e. 

atom:name ... text or html?

[Eric Scheid]

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.

Re: Atom syndication schema

[Eric Scheid]

On 15/3/06 2:21 PM, "Martin Duerst" <[EMAIL PROTECTED]> wrote:

>> Not sure if this is a known bug, but I just noticed that the RelaxNG
>> grammar doesn't accept "atomCommonAttributes" (eg xml:lang) on the
>> "atom:name" and "atom:uri" and "atom:email" elements used within
>> Person constructs.
> 
> For atom:uri and atom:email at least, not having xml:lang may
> be seen as a feature. While these often contain pieces from one
> language or another, they are not really in a language.

Since the original 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 names (eg. Eric Scheid) would be indexed as Scheid,
Eric; a comma is instead simply added between the Hungarian surname and
forename, making Hungarian names indistinguishable from other Western-style
names. For example: Bartók Béla is indexed as Bartók, Béla.

Icelandic names are another game altogether.

e.

Re: Browser behaviour

[Eric Scheid]

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 polls?

My aggregator of choice lets me browse the links in entries, including any
atom:links ... no reason it couldn't thus fetch a linked resource, and
specify the current feed as the referrer.

e.

Re: todo: add language encoding information

[Eric Scheid]

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 considering a client that didn't understand
> this extension would consider the full feed to be an alternative for that
> one particular entry which doesn't seem right.

Any reason that application/atom+xml document couldn't be an Atom Entry
Document, apart from the current lack of reader/browser support? It could
also then include the links necessary to subscribe to the specific language
feed.

e.

Re: Feed Thread Draft

[Eric Scheid]

On 26/1/06 4:23 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

> 

Re: new draft? (was: invention)

[Eric Scheid]

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
provides a stream of entries (in an Atom Feed Document).

The latter is the kind of thing that people want to subscribe to, but is
only a subset of the former. The former might include advertising web
services [1]

e.

[1] http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/ 

Re: new draft? (was: invention)

[Eric Scheid]

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.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 with
> it that is a feed of all the comments on that page.

Are the comments on the same html page, or on another page? Some websites do
it the latter way. It often depends on the size of the article, especially
if the article is split into multiple pages (eg.
 ).

In the first use case, it would make sense to have @rel="alternate feed
replies" (it's an alternate representation of the page, it's a feed of
updates of this page, and it's a resource containing replies to this page).

In the latter case however @rel="alternate feed replies" would be broken.
The replies are not on that page, so how is a feed of replies an alternative
representation? It would make sense to have @rel="related feed replies"
though.

> Regardless, the current spec is unambiguous, it points to
> feeds. If we want it to point to something besides a feed
> it has to be changed.

No, it does *not* point to "feeds", it points to resources of a certain mime
type of which a subset are feeds. There's the ambiguity.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 not orthogonal ("alternate stylesheet"
>> is not "alternate" and a "stylesheet", it's an
>> "alternate-stylesheet"), and further assigns meaning to the presence
>> (though not, exactly, the content) of a title attribute.
> 
> Marvelous.

Yeah, awful.

> Are you suggesting we promulgate that behaviour in
> the face of autodiscovery for RSS that already uses
> "alternate"?

Speaking for myself, quite the opposite.

Robert Sayre is the only one so far suggesting that @rel="alternate entry"
should be treated as excluding the semantic of @rel="alternate". Which is
surprising: I would have bet he would consider the "alternate stylesheet"
thing an abomination.

I'm suggesting that if we want to link to a resource which is considered to
be a feed for the current document we use "feed". If we want to link to a
resource which is considered to be an alternate representation of the
current document we use "alternate". If the resource is considered to be
both, then the x/html spec allows both relationships to be expressed in the
one  as a space separated list.

Specifying "feed" does not rule out using "alternate feed" for backwards
incompatibility purposes, except to those implementations that can't cope
with more than one value in @rel, and according to the autodisco 1.0 spec
they are broken anyways so I have no compassion for them.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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", and patches for "alternate
something-else", and patches for "alternate blah" and patches for "alternate
[anything but blank space]".

Yep, that's the smart way to write a spec. Write it such that
implementations need to patch around it's shortcomings. And of course these
use cases for patches won't be documented anywhere, and different
implementers will do different patches. Didn't we already go through this
with the bugs and ambiguities in the html spec?

> In fact, you don't even need a spec to help. Just start doing it. If it
> becomes common, there will be patches.

Why not just spec it properly now? We know this is a possibility, we know
that keying off "alternate" is casting too wide a net. This change is
backwards compatible, so why the resistance?

Anybody would think that wide deployment is an argument against making
things better. If so we'd all be doing stuff using gopher, not http; or
using html 1.0 not xhtml.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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",
according the current autodiscovery spec. That's the problem right there.

The spec should allow for the creation of other specs without land-grabbing
the non-specific "alternate" @rel value.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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-rel
> 
> I.e. the values are all orthogonal.

Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links

>> rel="alternate" href="1"
>> rel="alternate" href="2"
>> rel="alternate" href="3"
>> rel="feed"  href="1"
>> rel="entry" href="2"
>> rel="replies"   href="3"

Which is exactly what was intended.


e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 semantics to cover
> everyone¹s use cases, and no single app will ever understand all
> of these disparate semantics.

Strawman. I'm not suggesting we pre-define all these other cases. I'm
suggesting we define this one case (here is a feed document related to this
page) in a manner which distinguishes it from other [undefined] cases.

> The problem seems simple while you
> look at it with blog-coloured glasses because that is such a
> small and well-understood niche of the problem space.

Be careful what you assume. I'm thinking of using atom entry documents for
many non-blog related purposes, and this is what is driving my interest in
disambiguating feed autodiscovery.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 weak, I know.

@rel contains tokens, @title contains human language content.

Would @title="Entrada com comentários" also be acceptable? How about
@title="Entrata con le osservazioni" or @title="Entrée avec des
commentaires" or @title="Entrada con comentarios" or @title="Eintragung mit
Anmerkungen"? No. This is no basis for auto-whatever.

No matter what the @lang might be, the @rel would still contain the same
token for each of those possible @title links. It's just English Language
Imperialism why it happens to be "alternate entry", it could just as easily
be specced to be "FooBarBaz" or "3576.24352.987".

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 link points to.

Unambiguous? The autodiscovery spec does not outlaw using
[EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry
documents. It only says that such links may be used to find Atom Feed
Documents. This is a subtle nuance.

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 with the
> autodiscovery draft.  We have the same problem differentiating
> .  This isn't a
> problem that the autodiscovery draft needs to solve.  If it's a problem,
> solve it in the Atom format spec where the media type is defined.

Too late. It would have been nice to have "application/atomentry+xml"

Also, fixing it in the atom format spec doesn't fix the exact same problem
autodiscovery has with "application/rdf+xml".

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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?

PaceDifferentRelValue addresses this. It suggests using "feed" as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to. It doesn't rule out continuing to use
"alternate" for those cases where the feed is actually an alternate to the
current document.

> I am trying to think of a scenario where I¹d want to autodiscover an entry
> document (as opposed to simply linking to it) and the inability to distinguish
> between feed and entry documents is causing a problem, but I can¹t come up
> with anything. Can you provide an example?

I'm not talking about autodiscovery of entry documents. I'm talking about
autodiscovery of feeds, which (and this is the point) is *different* from
autodiscovery of resources with the mime type of "application/atom+xml".

Apart from Atom Entry Documents, there are also "application/ref+xml"
documents ... and not all of those are RSS 1.0 feeds.

Using "feed" solves the problem for both cases (atom entry and rdf+xml), and
potentially any similar problems (eg newsml+xml?).

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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/should never
appear in x/html pages?

e.

Re: finishing autodiscovery, like now

[Eric Scheid]

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 spidering. But `rel` does not
> add any information.

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?
 
> In fact, semantically, we should be encouraging people to move
> things out of their ``s and into ``s in the page.

Sounds like PaceAnchorSupport. How do you propose we do this encouragement,
if not by codifying it into a spec?

On 20/1/06 4:05 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> The spec is extremely well-written and reflects existing behavior.

The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That doesn't meet my definition of "well-written".

e.

Re: partial xml in atom:content ?

[Eric Scheid]

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.

Re: partial xml in atom:content ?

[Eric Scheid]

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.

Re: partial xml in atom:content ?

[Eric Scheid]

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:
> 
>   
>   
>   
>   
>   
>   
>   
>   

No, that isn't one entry in a collection of atom categories, that is one
entry in a collection of *bundles* of atom categories. That's as wrong
headed as trying to squeeze *three* images into the one atom media entry.

If I have three categories in the collection, then they would be in three
individual entries.

> An atom:content with an XML media type MUST have exactly one
> child element, so you can¹t do that. You need to wrap those
> categories in something. The manifest choice is atom:entryŠ

If I have a collection of atom:categories, the atomic unit is one
atom:category. So having a collection where each entry has *one*
atom:category in the atom:content element is what I would be trying to do.

If I wanted to have a collection of _bundles_ of atom:categories, I'd
probably need some foreign element to act as the bundling element (eg.
)

> Which just so happens to be a valid root element for
> `application/atom+xml`. Of course, you¹re pulling in an entire
> train of metadata elements at that point, which will probably be
> completely redundant, so whether that is any help I don¹t know.

I don't want that train of metadata. I already have an atom:entry with which
to carry metadata for that content. (Heh, I could even apply atom:categories
to that content, same as any other content ;-)

The last niggling concern is with atom-format: although atom:content can
contain XML, can that be *any* XML data, or does the spec forbid atom+xml
from there? What will the validator do?

e.

Re: partial xml in atom:content ?

[Eric Scheid]

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 unless
> it was a proprietary feed communicating between two known applications.

then you're not going to like what I was thinking of doing ... posting
 chunks to an APP/media collection, such that the media
collection entry might look like this (no typos this time, I hope)...


...





Thus, in the same sense I might have elsewhere a collection of images, I
have here a collection of atom categories.

I can hear the screaming already.

e.

Re: partial xml in atom:content ?

[Eric Scheid]

On 16/1/06 1:57 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

>>   
>>   ...
>>   
>> 
>>   
>>   
>> 
> 
> Heh.. another typo methinks ;-)

grrr! TooEarly - SufficientCoffee = Typos

e.

Re: partial xml in atom:content ?

[Eric Scheid]

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.3.3

4.  If the value of "type" is an XML media type [RFC3023] or ends
with "+xml" or "/xml" (case insensitive), the content of
atom:content MAY include child elements and SHOULD be suitable
for handling as the indicated media type.  If the "src" attribute
is not provided, this would normally mean that the "atom:content"
element would contain a single child element that would serve as
the root element of the XML document of the indicated type.

Assume foo xml requires foo:basket as the root element. Is it valid to have
atom:content with foo:thing as the immediate child?

For example, an OPML document requires  as the root, which contains
 and , the latter containing  elements ... so can an
atom entry contain just an  element?

  
  ...
  

  
  

Thus, can atom be used to ship around parcels of xml snippets? I suppose it
could, but only so long as both ends knew what was going on, and knew naïve
atom processors might barf on the incomplete xml, right?

e.

Re: partial xml in atom:content ?

[Eric Scheid]

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.

partial xml in atom:content ?

[Eric Scheid]

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 specs state that there must be a certain root
element (similar to how atom documents must have either  or  as
root elements)?

e.

Re: examples of merged feeds/feed aggregation?

[Eric Scheid]

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.

Re: clarification needed: order of children of atom:entry

[Eric Scheid]

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.

clarification needed: order of children of atom:entry

[Eric Scheid]

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, otherwise this:




heading
para.1
para.2


...


... could become the following when passing some intermediary:




para.2
para.1
heading


...


e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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

Re: Sponsored Links and other link extensions

[Eric Scheid]

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
name and/or location. Lots.

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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.
>> 
>> What do you get in return? ³It looks more XMLish²?
>> 
> 
> yes!? We are using xml!

not only that, but if someone wants to write another extension (gasp!), it
would be very easy to fold it in, using native XML methods...







(not that I can think of any such extensions, but why be a bastard to future
inventors and innovators?)

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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 (ooh, look, some alternate href's!)

> If an implementor has to support alternative links explicitly for each type of
> main link, where¹s the difference to having specific relationships for
> alternative links depending on the main link type?
> 
good point.

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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 elements and iterating over it.

There's another problem with this:

>   @encl:mirrors="http://www2.example.com/file.mp3
>http://www3.example.com/file.mp3";

... how do you attach @title to each URI,

for example @title="Blah blah -- European Mirror".

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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 clients already
get.

With this approach dumb clients do no harm, and smart clients gain benefits
not available to dumb clients. It sets up the right ecological pressures for
the market to evolve in a way which is beneficial.

So while "let the market/implementations decide" is often persuasive, we
really should at the same time be asking what environment/ecology are we
establishing for this evolution.

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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="application/ogg"
>   href="http://example2.com/file.ogg";
>   encl:alternative-to="x-file"
>   />

-1 ... this is starting to get ugly.


e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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 the duplicate bandwidth problem again :-(

> If you combine this with the requirement that an inner link with the same
> type and hreflang as the outer link must be bit-for-bit identical, we could
> cover the other use-case of multiple download sources. So far, no new
> elements or attributes necessary.

what about the use case of alternate formats (etc) for the same resource?

> Not sure about the legality.

not legal, since atom:link cannot appear there ie. while atom:link (the
container) can contain foreign markup, atom:link (the embedded) is not
foreign markup.

e.

Re: New Link Relations -- Ready to go?

[Eric Scheid]

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 link to a "table of contents"
> feed allowing navigation to e.g. snapshots of non-incremental feeds;
> another link relation for the "webring" use case if it proves to be needed
> one day).

+1

Re: Sponsored Links and other link extensions

[Eric Scheid]

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://example2.com/file.ogg"; />
> 
> 
> (b)
>  href="http://example.com/file.mp3"; />
>  href="http://example2.com/file.ogg"; />

With (b), how could you ever then provide multiple distinct enclosures for
an entry. With (b) you're trying to say that the two sound files are the
same thing, just different formats.

For example, I might want to provide a movie file with commentary, and
another movie file without commentary, and a third movie file showing just
the special effects part in slow motion. They are not substitutes for each
other.

With (a), we know the .mp3 and the .ogg are simply different formats of the
same thing. With (b) we don't know either way.

> What I want is a way of indicating that a particular resource is
> available at multiple locations.  I'll use multiple link elements to
> indicate that there are multiple formats.

And some aggregators will treat that as a basket of different enclosures and
try downloading all of them.

>> it would be fair to say that any two x:alternate with different @href's but
>> equivalent x:md5 are mirrors. That can fit into the model with no other
>> modifications :-)
>> 
> I would argue that the x:md5 for all alternates should be the same as
> the parent link.
> 

What about this though:


  







  
  

  


Here we have an entry with two enclosures. The first enclosure is the
soundtrack, and is available in mp3 from one primary URI and three mirrors,
and also available in .ogg from three mirrors, and for the truly desperate
also available as a .wav file. The second enclosure is a commentary sound
track, but not available in any other formats or from any other mirrors, but
there is a Portuguese translation variant if you (really) want.

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

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 these resources are
> bit-for-bit identical. If not I think they MUST include an x:md5 attribute
> so an aggregator can tell which are safe to interleave.

that's a different direction, but an interesting one.

What we were thinking was along the lines of saying: here is enclosure in
mp3 format, but it's also available as ogg, wav, and in hreflang="fr-CA" for
you Canadian rebels.

it would be fair to say that any two x:alternate with different @href's but
equivalent x:md5 are mirrors. That can fit into the model with no other
modifications :-)

e.

Re: New Link Relations -- Ready to go?

[Eric Scheid]

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 there to support autosubscribe.  But, it turns out, only in the
> special case where the feed is static and you wouldn't actually
> subscribe to it. I think the risk of confusing implementors and
> weakening the value proposition around  exceeds the benefit of supporting this special case.

I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link would
happen to match the 'subscribe' link, which is the exception. The defining
text in the spec says this about 'self'

The value "self" signifies that the IRI in the value of
the href attribute identifies a resource equivalent to
the containing element.

atom:[EMAIL PROTECTED]'self'] can also appear in atom:entry, which would be used
for pointing to Atom Entry Documents, which explains why the text says "the
containing element". I don't believe anyone is thinking we should be able to
subscribe to Atom Entry Documents.

> Plus, I think the thing isn't properly named.  It isn't actually
> "subscribe in the general case",

Are we yet in a situation were we have a preponderance of deployed feeds
using 'self' to mean 'subscribe'? Actually, that's the wrong question to ask
(see below)

Are we yet in a situation were we have preponderance of deployed
applications that look for 'self' for subscription purposes?

I think we're in the early days of Atom 1.0 adoption, and we can very likely
talk up via blogs, articles, etc the idea of "subscribe in the general case"
using @rel='subscribe'.

The only deployed inertia we have to over come is with aggregator
developers. We don't have to worry about any deployed feeds that only have
'self' links (I'll explain in a moment). We only need to explain things to
the various aggregator developers. The general idea would be for the
application to look for a 'subscribe' link first up, and failing that a
'self' link. Very simple.

We don't have to worry about deployed feeds with 'self' links. They won't
have 'subscribe' links unless they put effort into putting them there, in
which case they could quite simply s/self/subscribe/. If a feed does not
have 'subscribe' then 'self' would be found with the fall back.

Could there eventually be feeds out there with only 'subscribe' and not
'self' ... they would be funky but not invalid (it's a SHOULD requirement,
not a MUST) ... and the only applications that would fail to subscribe would
be outdated p.o.c.

> it's "in the special case where the
> version you are looking at is static, point to the places where the
> changes happen because they don't happen here".  So, perhaps we
> should consider rel="current-self" or rel="dynamic-version" or some
> such.

I'm thinking is that 'self' was not properly named in the first place. If
the intent of that link was for subscription purposes, for pointing to the
most recent updates for that feed, then it should have been named
'subscribe' or (as you say) a descriptive word indicating that is the sort
of thing one would want to do with it.

The idea of embedding a link to the URI to subscribe to was a very good one.

Calling it 'self' was a bone-headed one. We were so caught up with the idea
of being able to subscribe to the active feed we forgot to consider the case
of seeing that link in the context of an archive.

This is the same class of bone-headed mistake as using
/html/head/[EMAIL PROTECTED]'alternate',@type="application/atom+xml"] for feed 
auto
discovery. Consider for example this HTML page...



Archive for January 2005



...


Now, one of those two links points to the URI you should subscribe to if you
want to see the most recent updates, and the other link points to a URI
which will give you the Atom Feed Document for the Archive for January 2005.
Only problem is, you can't tell them apart.

We painted ourselves into a corner.

This 'self' thing is the same class of error as 'alternate'.

Can we please learn from that mistake?

> Finally, markup design that claims to enforce a specific action is
> always questionable.  The great virtue of descriptive markup in
> general is that the tags tell you not what to do with things but what
> they are.  So on that basis, rel="current-version" or something is
> better design.

The verb/noun thing is a good point ... but how could 'self', which
generally speaking, would point to a completely different set of data, be
considered "descriptive"?

FWIW, @rel="subscription" was offered up first, but then got switched to
'subscribe'.

e.

Re: Application for addition to Atom Registry of Link Relations

[Eric Scheid]

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 that the
>>>informational content has been published under multiple copright
>>>licenses.  In such instances, each of the linked licenses is
>>>considered to be mutually exclusive of the others.

but the second bit of text suggests that the following is allowable:





which is a situation which should be allowable (IMHO), and so the
restriction should be removed:

>>>o  atom:entry, atom:feed and atom:source elements MUST NOT contain
>>>   more than one 'license' link relation with the same
>>>   combination of type and hreflang attribute values.

e.

Re: New Link Relations -- Ready to go?

[Eric Scheid]

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 believe we're in a moment of grace right now and we could, with a bit of
public advocacy, get 'subscribe' established and supported for one-click
subscription.

> For these two (similar) reasons I think it might be wise to keep
> rel="self" in the role that this new rel="subscribe" thing is
> supposed to fulfill, and invent a new relationship that can point
> to the canonical location of the archive feed document.

This occurred to me too, but I had my reservations about it.

http://www.imc.org/atom-syntax/mail-archive/msg17284.html

where I wrote:

Fortunately, the link relation 'self' was defined in such a woolly
way we could get away with re-purposing it. A few articles here or
there, a bit of blog chatter, and the arrival of the fabled Developers
Guide and we'd be set.

I'd think this would be favourable to having to come up with a
different pair of relations, like

'self'   = what you subscribe to,
   may not look anything like the chunk in front of you

'this-chunk' = link to what you are looking at,
   not to be confused with 'self'

e.

Re: New Link Relations -- Ready to go?

[Eric Scheid]

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 was
thought that the 'self' link in an archive would point to the archive
document itself, which meant a different relationship was needed for the
purpose of locating the URI which is the one that contains the most recent
updates/entries.

Start somewhere near here:
http://www.imc.org/atom-syntax/mail-archive/msg17208.html

e.

Re: New Link Relations -- Ready to go?

[Eric Scheid]

+1 to all

Re: Feed History / Protocol overlap

[Eric Scheid]

>>> 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 a useful
>> distinction IMHO. "
> 
> You said that to me about next and previous for app:collection when I
> requested the value 'next' be changed to 'previous' to be  consistent
> with the notion of elements existing earlier in time.

> What's different here?

Nothing. 

I should have been more clear back then that I was +1 on 'previous'... my
point was directed at Joe (not you), and that his line of argument (in
favour of 'next') was not persuasive and so if he wanted 'next' then he'd
better try another line of argument.

As then as now, I'm still +1 on 'previous' for going backwards.

e.

Re: General/Specific [was: Feed History / Protocol overlap]

[Eric Scheid]

On 20/10/05 3:12 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:

>   b) a generic relation, e.g., "previous"

+1

Re: Feed History / Protocol overlap

[Eric Scheid]

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*, you copied that, it's confusing, why
enshrine it into official specs? Why not take this opportunity to make a
better choice?

I looked at Pilgrim's atom feed document for March 2004 ... it said the next
document was February 2004 and the previous document was April 2004. Try
explaining to anyone that isn't writing an aggregator why that makes sense.

There are entries written in March which are a continuation of a story
written in February. So no, his feed is not reverse chronological.

You might want your aggregator to process various feeds in a reverse
chronological manner ... so please use the 'prev' link to go _backwards_
through the feed, and the 'next' link to go _forward_ through the feed.

Though there may be many Atom 0.3 feeds out there now, all those Atom 0.3
feeds will need to be rewritten for Atom 1.0. Even so, all those Atom 0.3
feeds are, you must admit, just a drop in the ocean of the potential
deployment of Atom 1.0 feeds from many many content publishers. Count the
number of websites that have semi-regular news, count the number of websites
that have feeds (of any flavour) ... it's a drop in the ocean. Now count the
number of aggregator developers..

e.

* and it's not the only poor choice that we're stuck with right now.
Consider how you might link from an HTML page which is the monthly archive
of your blog to an Atom Feed Document which is the XML representation of
that same content. We know what @href and @type to use ... but the
@rel='alternate' is already taken for the semantic of "subscribe to this
feed for ongoing updates". Thankfully we're avoiding that snafu with
@rel='self' vs @rel='subscribe'.

Re: Feed History / Protocol overlap

[Eric Scheid]

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-chronological series of feeds?

e.

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

[Eric Scheid]

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 archives.

Why choose "archives" over "history" to the exclusion of other types of
archives?

e.

Re: Feed History / Protocol overlap

[Eric Scheid]

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.

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

[Eric Scheid]

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 documents, paging is navigation from one to the other, following
> the sort order.

... and the subset of entries which are on page 1 sorted by one axis would
be very unlikely to be on page 1 when sorted by some other axis.

d'oh!

> If you want to provide the exact same entries sorted (thus paged)
> differently, then that's another feed.

unless of course each feed document contains only one entry each ;-)

e.

Re: Are Generic Link Relations Always a Good Idea? [was: Feed History -04]

[Eric Scheid]

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, it would reference another feed document where each
> entry describes an archive:

The word 'archives' is too general though. May I suggest @rel="history"
instead?

Otherwise, +1

e.

Re: New Link Relations? [was: Feed History -04]

[Eric Scheid]

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.

Re: New Link Relations? [was: Feed History -04]

[Eric Scheid]

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 resource equivalent to the containing element.

thus a link with @rel='self' in the  element would link to that
archive feed document. Similarly, a link with @rel='self' in the 
element would link to a resource document of that particular entry.

Thus (in context of )

'self'  = identifies a resource equivalent to this 
'subscribe' = identifies the resource to subscribe to

The same holds true for archive feeds and the current sliding window chunk,
which makes life easier.

e.

Re: New Link Relations? [was: Feed History -04]

[Eric Scheid]

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 solve the feed subscription problem.
However, I don't recall that the issue of feed archives featured much in
that discussion, and that thus the now understood problem of 'self' vs
'subscribe' wasn't envisaged.

Fortunately, the link relation 'self' was defined in such a woolly way we
could get away with re-purposing it. A few articles here or there, a bit of
blog chatter, and the arrival of the fabled Developers Guide and we'd be
set.

I'd think this would be favourable to having to come up with a different
pair of relations, like

'self'   = what you subscribe to,
   may not look anything like the chunk in front of you

'this-chunk' = link to what you are looking at,
   not to be confused with 'self'

(Maybe the Developers Guide will have a chapter called "Up Is Down - The New
Reality", which would explain that a link to 'self' doesn't, we use 'next'
to go backwards, and 'alternate' for feed discovery may not point to actual
alternates of the content in front of you ;-)

> Otherwise, +0.5, because it seems to overlap @rel="first" (or "last"?) ­
> or I missed somethingŠ

There's nothing wrong with having an overlap like this, because they don't
always overlap. Consider the 'subscribe' link to nature.com/nm/ which I
described earlier - two different URIs, but the same eventual document.

e.

Re: Feed History -04

[Eric Scheid]

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
> decided for the new protocol I would feel obliged to support that old
> protocol as well. If the two disagree that makes the process somewhat more
> complicated.

That article was written for Atom 0.3. We are now Atom 1.0. That particular
feed which happens to follow that so-called spec is also Atom 0.3, which is
of course deprecated.

I've been amusing myself with a thought experiment this morning too. Say I
had a set of feed documents, all arranged from "hottest" to "coldest" using
@rel='hotter' and @rel='colder'. There are no other links in the feed
documents. Say for the sake of argument that the most efficient manner for
an aggregator to traverse that set is to start from the hottest, and proceed
towards the coldest.

Remember, there are only two @rel values in the feed: 'hotter' and 'colder'.

Which links should the aggregator follow:

(a) @rel='hotter'
(b) @rel='colder'
(c) @rel='next'

> Everything else you say, while perfectly reasonable, does not inspire me to
> accept the extra effort involved without at least a mild protest.

All those 0.3 feeds should disappear in due course. That article was
specifically addressing Atom 0.3, and so too should not be relied on.

e.