Re: [FeedValidator] Validating dates

[If this was Usenet I'd set Followups to rss-dev or similar; this is
certainly OT for feedvalidator-users.]

Bill Kearney <[email protected]> wrote:

> > > While that might be useful for HTML web pages it seems like a somewhat
> > > bad idea for what's intended as machine-readble XML files.
> >
> > Surely the XML files we're talking about (feeds) are just as much or as
> > little 'machine-readable' as HTML web pages?  I said the framework is
> > there, not that I use it to generate my feed dates!
> 
> Well, how a web framework might 'adjust' it's output for incoming HTML
> browsers is probably quite a bif different than how XML output for a feed
> should be produced.

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.

> All readers are supposed to be able to process a feed. There aren't
> expected to be different versions based on different incoming RSS reader
> user-agents.

Absolutely!

> Where it REALLY gets messy is how the embedded RSS
> tools inside Firefox and IE7 all look like a browser to the web server.
> Thus the web server diligently adulterates the contents of the XML thinking
> it's HTML.  Bad idea.  Works great for web pages though.

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

[stuff about User-Agent sniffing in feeds which I don't disagree with]

> > Atom even goes so far as to explicitly state which bits are 'language
> > sensitive' and which bits aren't.  I'd have thought the bits that are
> > are crying out to be translated according to the standard HTTP
> > mechanisms.
> 
> Oh you're wandering down a very messy road when you talk about language
> issues in feeds.

Oh yes (but that is the only thing I was talking about).

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.

And then there's the issue of <atom:id>s...

> > > It's probably fair to say you don't want to process the data at all.  At
> > > least nowhere near the same way as how the HTML pages might get handled.
> >
> > Yes, that is probably fair.  In my case, our feed generating scripts
> > don't go through the same templating mechanism as our web-page
> > generating ones (where our web designers have complete freedom over
> > which bits get translated and which don't, and over the structure of the
> > output).  But they do share the same code for interpreting HTTP language
> > headers and fetching translated content from our database.  I use it
> > when it's appropriate, <atom:content> being the most obvious example.
> 
> It's apparent that not everything will benefit from being 'interpreted' in
> that manner.  For example, in a feed there's absolutely no need to alter how
> a date appears.  It's 2822 or 8601 style, period.

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

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

> For a web page, however, it
> would seem like a perfectly reasonable idea.

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" ... />)

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

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.

[...]

> Using translation mechanisms on web pages has worthwhile benefits, but not
> without carefully crafting the HTML pages to us it properly.  A feed might
> benefit similarly, but not without similarly careful processing.

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

Regards,

Peter
-- 
Peter Robinson
<http://www.ticketswitch.com/> Concerts, sport and theatre tickets


 
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/