Re: [FeedValidator] Validating dates

> Bill, I think we're mostly agreeing violently.  I don't ever change my
> output (xml or html) according to User-Agent, and I think that's about
> as evil on the web as it would be for feeds.

Heh, indeed, violently so.  Always thought that was an odd saying.

> Does it?  Mostly it just seems to prevent me from using the browser I
> want to to do my online banking!  Perhaps there's a lot of really good
> User-Agent sniffing going on that works so well I'm not aware of it...

Some frameworks can do effective things based on knowing the incoming
browser.  One example is the ASP.net 2.0 framework, it understands how to
send user controls to the remote client based on the user-agent.  But I'd
imagine there are more "broken" frameworks that get it wrong (or are
mis-applied) than situations where it works.

> HTTP language negotiation works perfectly for direct subscriptions (if
> supported by the reader), but not so well (I imagine) for web-based
> aggregators like Syndic8.  For Syndic8 I could provide different
> 'autodiscovery' <atom:links> to feeds with a hard-coded language
> parameter in the url, but that defeats my beautiful HTTP language
> negotiation if someone subscribes to one of those hard coded links using
> a standalone reader.

There's no defined mechanism for negotiating language with feeds.  That and
plenty of readers are multilingual.  I've always found it's better to let
users of a given language select one in that language independently of
whatever 'default' language might be used.  That and none of the readers
(I'm aware of) make proper use of language requesting in the first place.
I'm not sure that's a bad thing.

> Absolutely: what the OP was apparently doing was unquestionably wrong.
> But I'm not doing that!

Well, I don't want to characterize anything as "unquestionably wrong" just
not an ideal practice in the context of feeds.  While it's true the dates
were being improperly adulterated I'm sure the other aspects of the
framework might offer useful mechanisms.

> > No localized names of months, days or ordering changes are needed.
> It's not simply 'not needed': if you do that you get an invalid feed.

We once again agree.  I was more illustrating the point of why something
might want to adjust between database values and display formats.  There's
no need to do this for feeds but it certainly has merit on an HTML page.

> For displayed dates sure, but there's at least one place in HTML where
> you have machine interpreted dates just like you do in a feed.  (<meta
> name="date" ... />)

Excellent point.

> If you had a date in the free-form text of your RSS <description>, it is
> perfectly reasonable IMHO to translate it if you can.  (Along with the
> rest of the text.)

Yes, quite useful.  Presuming you've effectively identified the actual
cultural/localization methods used on the requesting client.

> In my case it doesn't work like that because my <description>s are just
> blobs of free-form text with no internal structure or templating.  But
> that's a limitation of my system rather than a deliberate choice.

Yeah, it might be fair to say one could take the idea "too far".

> That's one of the good things about Atom.  While it might be obvious to
> you and me which bits of a feed may be translated, and which bits should
> never be, when I wrote my Atom feed generator I didn't need to think
> about it because I could translate (some of) only those elements
> explicitly marked in the spec as 'language sensitive'.

I'm curious, what tools have you seen that effectively handle them?

-Bill Kearney



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/