Re: atom:name ... text or html?
On Fri, Mar 24, 2006 at 03:16:18AM +1100, Eric Scheid [EMAIL PROTECTED] wrote a message of 10 lines which said: or should I be using the unicode numeric entity instead? Or the character itself, in UTF-8 or any other encoding (but UTF-8 is the most widely implemented, so you limit the risks). (That's what I do with http://www.bortzmeyer.org/feed.atom and it seems OK in every agregator and it validates.)
Re: atom:name ... text or html?
On Thu, Mar 23, 2006 at 05:01:03PM +0100, Sylvain Hellegouarch [EMAIL PROTECTED] wrote a message of 11 lines which said: Because as a French, having accents in names is so natural that I see it as human readable too ;) As I wrote and used and tested on my blog, there is no problem in Atom to have a first name with accent like mine. Atom is XML and therefore Unicode rules.
Re: Atom syndication schema
On Tue, Mar 14, 2006 at 10:23:55PM -0800, Walter Underwood [EMAIL PROTECTED] wrote a message of 29 lines which said: xml:lang isn't enough information to sort out given name and family name. Yes! In many countries, the order changed. In France, one century ago Family-name Given-name was common in official papers but is now deprecated. In Algeria, a former french colony, the two usages still prevail (Matoub Lounes or Lounes Matoub?)
Re: Atom syndication schema
On Tue, Mar 14, 2006 at 10:36:36PM -0700, M. David Peterson [EMAIL PROTECTED] wrote a message of 43 lines which said: As long as your character set for any given feed is properly set, it seems to me then all the information necessary to properly decode the email and URI (in which the work continues to integrate support for non-latin based languages, such as Mandarin, etc... Just to be pedantic, URIs (RFC 3986) are in pure US-ASCII. IRIs (RFC 3987) are in Unicode and are accepted by Atom (so, Atom's URIs seem to be actually IRIs). The standard says: # Unconstrained; it's not entirely clear how IRI fit into # xsd:anyURI so let's not try to constrain it here atomUri = text if I understand things correctly, full support for Mandarin Chinese-based domains in not far off (speaking in terms of DNS support and such). It is quite old, RFC 3490 (issued three years ago and implemented even before). email adresses encoded as mentioned There is not yet any standard for Unicode email addresses (work is going on, see the very recent IETF Working Group EAI http://www.ietf.org/html.charters/eai-charter.html).
Atom features support in readers?
Is there somewhere a comprehensive survey of the current level of support in readers, with details for each feature, specially the most Atom-specific? I tested content=xhtml support for several readers and none does it properly. I would like to have information for other readers. (Remember also the discussion here about the support of updated.)
Re: Reader 'updated' semantics
On Tue, Jan 10, 2006 at 04:58:12PM -, James Holderness [EMAIL PROTECTED] wrote a message of 31 lines which said: There are a couple of options for an aggregator author. They can mark an entry as having changed when 1) the content of the entry has changed; 2) the updated element has changed; 3) the updated element has changed as well as the content having been changed; or 4) do nothing at all. I'm sure there are other possibilities, but I think those are the main issues. This is, IMHO, a completely different issue from the one asked by the OP. In Atom, it seems to me that 2) is the only reasonable choice (1 or 3 would require to store the content - or at least a hash - and, if applied blindly, would create many false positives since a simple reformatting of the XML would trigger a change). The question asked by the OP was: when updated was changed, what the reader should do? (And my reply was Interesting question but a bit out of scope for the atom-syntax group.)
Re: Reader 'updated' semantics
On Tue, Jan 10, 2006 at 10:35:27AM -0800, Tim Bray [EMAIL PROTECTED] wrote a message of 14 lines which said: There's a word for behavior of RssBandit and Sage: WRONG. Read again my message. Sage does *not* ignore changes of updated. Its behaviour is perfectly right. It just displays updated entries in a more discreet way than new entries. Software that chooses to hide this fact from users is broken Sage does not hide it. Test before criticizing.
Re: Reader 'updated' semantics
On Tue, Jan 10, 2006 at 05:32:08PM +0100, A. Pagaltzis [EMAIL PROTECTED] wrote a message of 37 lines which said: I don???t think it???s controversy, so much as that most people apparently simply don???t care whether an entry they???ve already seen has changed. It is also may be because feed writers are too eager to set updated when the change is insignificant (for instance, when there is simply a reformatting). In Atom, the specification is, IMHO, very clear: RFC 4287, 4.2.15. The atom:updated Element The atom:updated element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all ^ modifications necessarily result in a changed atom:updated value. But it is much more muddy in the RSS world which may explain why feed reader programmers tend to ignore updated. Developing best practices in this area is complicated because there is a strong interaction between the feed writers and the reader software. PS: Wikipedia allow authors to check a box Minor update when they modify a page and they don't want it to be regarded as a significant change. I wonder how many authors set it. It would be a nice Usability study to examine that.
Re: Reader 'updated' semantics
On Tue, Jan 10, 2006 at 07:06:59AM -0800, James Yenne [EMAIL PROTECTED] wrote a message of 39 lines which said: RSS Bandit does not provide an indication of an updated entry since many differ on what constitutes an update and what level of feedback should be provided to the user. Sage displays entries sorted according to updated but does not highlight updated entries, only new ones (new == new id). I believe it is partly an User Interface and Usability issue and therefore out of scope for the Atom-syntax group.
Re: Tag URIs
On Sun, Dec 18, 2005 at 12:01:39AM -0500, Alan Gutierrez [EMAIL PROTECTED] wrote a message of 25 lines which said: I'm to understand that Atom has adopted the Tag URI as a a perferred GUID for an Atom 1.0 feed. I've begun to use the Tag URI in my work. RFC 4151 (on tag URIs) is not even mentioned by RFC 4287. (Although one example use these URI.) It is instead an opaque URI. It seems perfectly normal: the tag URI has a structure only for the purpose of *creating* an unique identifier. For *reading* it, it should be regarded as opaque. It is not even resolvable (and does not pretend to be). Had Tag URI been specified as a heirarical, the parser would be able to extract more payload from the URI. To do what?
