Re: [FeedValidator] Validating dates

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

> Most humans aren't going to see the html source without a browser
> processing it either.

That's not the point, the point is a web server framework may well have to
adjust the HTML output depending on what gee-whiz server-side and client
integration features are being used.  As in, if it's a IE browser than use
ActiveX, while if it's plain old Lynx then don't bother.  Two ends of the
extreme, of course.  No RSS readers need such adjustments.

There is, potentially, some argument possible that certain reader programs
might benefit from being sent differing amounts of data.  If you knew the
remote client was using a browser that had no ability to process something
then leaving it out might be an idea to consider.  The only trouble is
you're then stuck in an endless loop making sure your framework stays up to
date with the remote client's feature set.  And then it's back to the same
mess we have in the 'browser wars'.

If I had control over, let's say, a set of remote users all on cellphone
devices.  If I knew that their reader programs had no ability to deal the
same range of data as regular desktop reader it might be worth stripping it.
If only to save a few bytes on the transfers.  But I'd be more incluned to
just use a different URL so they don't end up with subscription problems.
As in, the set they have on the phone ends up being different and then they
can't sync intelligently.  If anything it'd probably be better to use some
sort of gateway or proxy that did it instead of doing it at the source.

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

> > 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.  No localized names of
months, days or ordering changes are needed.  For a web page, however, it
would seem like a perfectly reasonable idea.  Take an internally stored date
and present it to a german-reading user with language specific wording and
culturally appropriate ordering.  That same user on a feed, however, would
have that done for them by the reader program at their end.

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.

-Bill Kearney
Syndic8.com



 
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/