Re: Browser behaviour

[A. Pagaltzis]

* Eric Scheid <[EMAIL PROTECTED]> [2006-02-02 03:20]:
>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.

How many of those point to Atom feed documents instead of
elsewhere on the web?

What harm would it do if these were served to your aggregator as
`application/xml`?

Regards,
-- 
Aristotle Pagaltzis // 

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: More on atom:id handling

[Danny Ayers]

On 2/1/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
>
> * David Powell <[EMAIL PROTECTED]> [2006-02-01 17:10]:
> >On the contrary, I have a problem with preventing multiple
> >revisions from having the same atom:updated value.
>
> But then you have no idea which revision will be picked by
> clients that try to show the latest one, which to me sounds like
> it fulfills the criteria for a potential interop problem, which
> is exactly what "SHOULD" is about, so I think this was the right
> choice.

It's not straightforward, this came up pretty quickly in the Atom/OWL
efforts. As Bill said, it's a composite key. In RDF/OWL that has so
far demanded a rule* - somewhat less convenient than having a single
URI as id. The question is, from what is the composite key formed? id
certainly, updated too - but is same id+updated enough? What if other
parts of the entry differ? Different xml:lang even...same entry or
different?

*see also : http://esw.w3.org/topic/CIFP

Cheers,
Danny.



--

http://dannyayers.com

Re: Browser behaviour

[Danny Ayers]

On 2/1/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

> How about this simple rule? If the request for a feed has a
> referrer, which aggregator presumably[1] never do, then serve as
> `application/xml` with all cache control headers set to expire
> immediately; otherwise, send as `application/xhtml+xml`. (Expiry
> prevents intermediaries from caching it with the wrong MIME
> type.)
>
>
> [1] My server logs confirm this assumption for at least 20
> different popular aggregators.

Cunning, but the result of presuming aggregators "never do" might mean
aggregators never can, and referrer refs. from aggregators may well be
useful.

Cheers,
Danny.

--

http://dannyayers.com

Re: Browser behaviour

[A. Pagaltzis]

* John Panzer <[EMAIL PROTECTED]> [2006-02-01 23:45]:
> > How about this simple rule? If the request for a feed has a
> > referrer, which aggregator presumably[1] never do, then serve
> > as `application/xml` [snip]
>
>Does this work for bookmarks?  (Thinking here especially of IE
>bookmarks saved to a desktop and double-clicked to start the
>browser...)

Hmm, that’s a catch. Probably not…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Browser behaviour

[John Panzer]

A. Pagaltzis wrote on 2/1/2006, 1:39 PM:

 >
 > * John Panzer <[EMAIL PROTECTED]> [2006-01-30 22:05]:
 > >This means that users might possibly end up subscribing to
 > >something of type application/xml if they copy and paste URL
 > >#3... but we could also make this client dependent so that, for
 > >example, everything other than known web browsers get
 > >application/atom+xml.
 >
 > How about this simple rule? If the request for a feed has a
 > referrer, which aggregator presumably[1] never do, then serve as
 > `application/xml` with all cache control headers set to expire
 > immediately; otherwise, send as `application/xhtml+xml`. (Expiry
 > prevents intermediaries from caching it with the wrong MIME
 > type.)

Does this work for bookmarks?  (Thinking here especially of IE bookmarks 
saved to a desktop and double-clicked to start the browser...)

-- 
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer

Re: More on atom:id handling

[A. Pagaltzis]

* David Powell <[EMAIL PROTECTED]> [2006-02-01 17:10]:
>On the contrary, I have a problem with preventing multiple
>revisions from having the same atom:updated value.

But then you have no idea which revision will be picked by
clients that try to show the latest one, which to me sounds like
it fulfills the criteria for a potential interop problem, which
is exactly what “SHOULD” is about, so I think this was the right
choice.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Browser behaviour

[A. Pagaltzis]

* John Panzer <[EMAIL PROTECTED]> [2006-01-30 22:05]:
>This means that users might possibly end up subscribing to
>something of type application/xml if they copy and paste URL
>#3... but we could also make this client dependent so that, for
>example, everything other than known web browsers get
>application/atom+xml.

How about this simple rule? If the request for a feed has a
referrer, which aggregator presumably[1] never do, then serve as
`application/xml` with all cache control headers set to expire
immediately; otherwise, send as `application/xhtml+xml`. (Expiry
prevents intermediaries from caching it with the wrong MIME
type.)


[1] My server logs confirm this assumption for at least 20
different popular aggregators.

Regards,
-- 
Aristotle Pagaltzis // 

Re: More on atom:id handling

[Thomas Broyer]

[on atom-syntax only, no need to CC atom-protocol]

2006/2/1, David Powell <[EMAIL PROTECTED]>:
>
> Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote:
> >
> > IIRC, it was to allow a feed listing "revisions" of the same entry:
> > same id, different "updated" values.
>
> I don't have a problem with allowing multiple revisions with the same
> atom:id in a single document at all; I think that is a good thing.
>
> On the contrary, I have a problem with preventing multiple revisions
> from having the same atom:updated value. It subverts the intent of
> atom:updated being a subjective element, and it puts the feed compiler
> in an impossible situation. Nothing prohibits the entry author from
> producing two different instances with the same atom:updated value,
> but given this valid situation, the feed compiler is forced to
> silently lose data.
[…]
> It also prevents synchronization applications, such as Microsoft's SSE
> from introducing a more discerning date/revision extension, because
> nothing is allowed to be more discerning than atom:updated, even
> though the specification admits that:
>
>   "not all modifications necessarily result in a changed atom:updated
>   value"

Totally agree.

You should add it to http://intertwingly.net/wiki/pie/RFC4287Errata

--
Thomas Broyer

Re: More on atom:id handling

[David Powell]

Wednesday, February 1, 2006, 3:20:23 PM, Thomas Broyer wrote:

> [CC'ing atom-syntax]

> 2006/2/1, David Powell <[EMAIL PROTECTED]>:
>>
>> Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote:
>>
>> > Entries in an Atom feed can share the same atom:id but their
>> > atom:updated values should be different.
>>
>> To be precise, it is "Entries in an Atom Feed Document" not "Entries
>> in an Atom feed".
>>
>> I really really dislike that rule, and don't understand how it was
>> ever accepted, and personally I would be tempted to ignore it.

> IIRC, it was to allow a feed listing "revisions" of the same entry:
> same id, different "updated" values.

I don't have a problem with allowing multiple revisions with the same
atom:id in a single document at all; I think that is a good thing.

On the contrary, I have a problem with preventing multiple revisions
from having the same atom:updated value. It subverts the intent of
atom:updated being a subjective element, and it puts the feed compiler
in an impossible situation. Nothing prohibits the entry author from
producing two different instances with the same atom:updated value,
but given this valid situation, the feed compiler is forced to
silently lose data.

And for what purpose? The restriction is useless anyway. If it is
trying to provide a strict ordering of instances within a feed, it
fails, because the restriction only applies within a feed document.
Two seperate polls of a feed document can still produce two different
instances with the same updated value.

It also prevents synchronization applications, such as Microsoft's SSE
from introducing a more discerning date/revision extension, because
nothing is allowed to be more discerning than atom:updated, even
though the specification admits that:

  "not all modifications necessarily result in a changed atom:updated
  value"


-- 
Dave

Re: More on atom:id handling

[Thomas Broyer]

[CC'ing atom-syntax]

2006/2/1, David Powell <[EMAIL PROTECTED]>:
>
> Wednesday, February 1, 2006, 6:21:12 AM, James M Snell wrote:
>
> > Entries in an Atom feed can share the same atom:id but their
> > atom:updated values should be different.
>
> To be precise, it is "Entries in an Atom Feed Document" not "Entries
> in an Atom feed".
>
> I really really dislike that rule, and don't understand how it was
> ever accepted, and personally I would be tempted to ignore it.

IIRC, it was to allow a feed listing "revisions" of the same entry:
same id, different "updated" values.

--
Thomas Broyer

Re: todo: add language encoding information

[Henry Story]

Thanks for the reminder. I had not completely swapped in the earlier  
parts of the thread.


1. Content translation
---

With the  hreflang pointing to the alternate content inside the entry


   Atom-Powered Robots Run Amok
   http://example.org/2003/12/13/atom03"/>
   http://example.org/2003/12/13/atom03/fr";  
hreflang="fr"/>

   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

we get the ability to point to any number of different language  
versions of the same document.
But this does not help the user who would like to find the  
translation of the metadata in his language.


2. Metadata translations


For translation of metadata (title, subtitle, summary and content are  
the ones that would be affected - any others?), there are a number of  
solutions:


2.1 Feed translations.
-

	As James Holderness points out below one can have the feed that the  
entry is contained in  point to a feed that contains the translated  
metadata feed. There was some discussion there about the best way to  
do that (self or alternate, if I recall correctly) but it is clear  
that there should be no difficulty there.


	One problem here is how to tell which entries in one feed are  
translations of which entries in the other.


 	a- One could simply find this out by giving the entries in both  
feeds that are translations of each other the same id. In web  
architecture terms the entries could be seen as different language  
representations of the resource named by the id. [[ but see problem  
with SHOULD restriction below ]].
	b- Otherwise one needs to be able to create translations (alternate  
language) link relations from entries to entries across feeds.



2.2. Entry Translations
---

  As Simon Phipps pointed out, for small players, translations are  
expensive. The creator of an entry may for example only have time to  
translate the metadata for a few of the entries for which he can see  
this to be of value. He may not even wish to translate the content,  
leaving that for someone else with a little more time perhaps to do.  
So we could have french metadata for content that is only available  
in english (but that may later become available in french).


   So here it seems that there is at least one use case requirement  
for having some way to tell that two entries in the same feed are  
translations of one another. Following the logic of 2.1 there should  
be 2 ways of doing this:


	a- Simply publish the two entries with the same id. Here the two  
entries are seen as two different language versions of the resource  
named by the id.
	b- We need to be able to create a translations (alternate language)  
link relation between two entries with different ids in the same feed.


Now solution (a) does not work in this situation because of the  
famous SHOULD level restrictions on when two entries can appear in a  
feed.


[[
  If multiple atom:entry elements with the same atom:id value appear in
   an Atom Feed Document, they represent the same entry.  Their
   atom:updated timestamps SHOULD be different.
]]

And the Swiss case shows that one may be obliged to publish two  
different language versions
simultaneously. But perhaps this is why we don't have a MUST level  
restriction, but only a SHOULD. And perhaps it really is permissible  
to have different language representations of the same entry id.


Even then we may still want some way to specify that two entries are  
metadata translations of each other (eTranslations in the graph).  
Perhaps someone wants to translate an entry of mine, but does not  
want to use the same entry id. They would then still want a way to  
specify the relation between the two ids. (note that in RDF one could  
solve this by saying that the two ids are same-as each other, and  
fall back to case (a)).



HOWTO
=

So how can we specify that two entries are translations of each other?

0. Entries have same id
---

If the two entries have the same id yet have different language  
settings, then when we come across both we should guess that these  
two represent the same thing.
	+ it would mean that an aggregator that had found one entry would  
know he need not ping his user to let them know about the new version  
in a different language.

- this does not help find a different language entry when one finds one

The biggest problem is finding a way to point from one entry to  
another. All entries have ids, but these don't tell us where we can  
get information about them. An atom id is usually not dereferenceable.


Also it is not clear that it would be understood that the new  
representation in a different language is not just meant to be a  
replacement of the old one. (See SHOULD level restriction mentioned  
above). [[ There needs to be a debate as to whether multilingual  
representatio

Re: todo: add language encoding information

[Henry Story]

On 1 Feb 2006, at 02:10, Eric Scheid wrote:



On 31/1/06 1:27 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:


Actually I was thinking just a regular href and type. For example:

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.


I think that was one of James' original suggestions. It seems like  
one good solution. The only problem is that it forces people to have  
Entry Documents.


I am just writing up a document listing all the different ways one  
can solve this problem...




e.