Re: Re: [FeedValidator] Validating dates

> > There's no defined mechanism for negotiating language with feeds.
>
> That's like saying there's no defined mechanism for caching, compression
> or encryption.  Feeds delivered by HTTP have a mechanism available;
> it's just that people like you and me have to decide whether using it
> makes sense.

It's not defined in the how RSS feeds are handled.  What's possible with
making HTTP requests in a browser are not necessarily mimicked in RSS
readers.  This is both a good and a bad thing, depending on what features
you're after.

> > That and plenty of readers are multilingual.
>
> You mean a bilingual French & German speaker might want to read one feed
> in French and one in German even if both feeds are available in both
> languages?  Certainly you're right that the 'transparent' HTTP mechanism
> doesn't cope with that at all.

And it's been my experience that no one solution works reliably enough not
to antagonize a really large part of the audience.  Language is such a
tricky area.  Made worse by developers often using only one language (often
english, but not always).

> Heh :)  All I meant was "unquestionably wrong" is the (language-based)
> adulteration of <pubDate> (or whatever it was).  No disrespect intended
> to the OP.  He was clueful enough to try to validate his feed, and he's
> probably fixed that tiny bug by now...

Yes, I didn't want the postings to the thread to look like anyone was being
overly harsh toward the original posting.  I'm not one for political
correctness but I have seen where discussions about language often get
dramatically misinterpreted.  I don't think either of us are missing the
point.  Hopefully nobody else will either.

> As for traditional HTTP-based language negotiation, Safari and Firefox
> certainly do it in their feed readers (as you'd expect).  I assume other
> browser-based readers will also.

Well, as the saying goes "when you ass-u-me...."  I wouldn't.  I've seen
some really bad examples of misconfigured browsers.  A worst-case scenario
is how to deal with data pasted into a korean web page served from an arabic
configured http server using a danish configured browser on a russian
configured OS.  There's four different places where "language" and
"encoding" is being set, which one's correct?  From what I've seen various
tools make their assumptions based on different parts, sometimes it almost
seems random.  Thus I think it leads to the classic problem of people
developing a "fixed" opinion on what's correct based on what are often
entirely INcorrect tool behaviors.  Basically, "my favorite tool says this
is OK so all the rest of you are wrong", more or less.  I don't have any
miracle answers here, just warnings.

I'm certainly in favor of feeds and tools having new features.

> I'm slightly disappointed to see that
> NetNewsWire doesn't.  Shame really since IMHO it would be perfect for a
> desktop aggregator like that.

Again, I think it's probably due to the usual situation of the developer
being focused on a given language and not being aware of or interested in
addressing some of the more subtle aspects of multilingual access.  I'm sure
if the issue was brought to any developers attention and explained
effectively they'd certainly be willing to consider adding features for it.
But, much like character encoding, language is a really poorly understood
facet of XML.

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