W3C home > Mailing lists > Public > public-html@w3.org > November 2009

Re: XML namespaces on the Web

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 18 Nov 2009 11:56:29 -0600
Message-ID: <643cc0270911180956n573b7c61m2507ef8db95063e8@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Julian Reschke <julian.reschke@gmx.de>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Liam Quin <liam@w3.org>, John Cowan <cowan@ccil.org>, public-html@w3.org
On Wed, Nov 18, 2009 at 11:03 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Wed, Nov 18, 2009 at 11:13 AM, Leif Halvard Silli
> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>> ... then I am not certain that Aryah and Lachlan agree 100% about how
>> it should work. It seems to me that Aryah's idea is (and I don't know
>> if Lachlan agree) that the user agent MUST make it clear that the
>> recovered version of the document is not XML anymore. Don't you support
>> this?
> No.  The UA doesn't make it clear when a document *is* XML, so why
> should it have to make it clear when it's *not*?  Users should not
> have to be informed whether the document they're viewing was written
> as HTML, XML, PostScript, or tiny dwarfs painting a picture on the
> inside of their monitor.  The difference is incomprehensible to most
> people and telling them would be pointless.
> Of course, UAs might provide this information to authors as a
> debugging tool if they liked.  If by "make it clear" you mean "put it
> in some hidden developer toolbox", then sure, they may as well.
>> But I realize that Aryah did not believe in text/HTML as the
>> recovery/error tolerant format due to all the special requirements that
>> text/HTML has.
> I'm not the only one.  Lachlan said something similar, and so have others.
> On Wed, Nov 18, 2009 at 11:31 AM, Shelley Powers <shelley.just@gmail.com> wrote:
>> I can understand the concept of fatal error, but draconian means
>> "extremely harsh and severe". I don't see that one needs to be
>> punitive when reporting an error, especially when parsing XHTML in a
>> browser.
>> Opera reports the error, but also provides very useful information
>> about the error. The application also provides the ability to re-parse
>> the page in more forgiving HTML. This is not draconian error handling.
>> ...
> Maybe not, but it doesn't work for other XML-based formats, like RSS.
> In those cases, there's no standard error-handling mechanism, so
> clients either have to fail fatally or do something that's not
> interoperable.  It would be nice to be able to design formats that can
> be safely authored using just echoes and string functions, but which
> are less insane than text/html.

I don't see any harm for feed aggregators rejecting a feed or feed
entry for malformed XML. In fact, the one I'm using currently does
this. When it updates, it provides status about feed parsing, and if
there's an error, posts a note that there's a problem with the one
feed. I've used this to send emails to folks, letting them know they
have feed errors. Most people are thankful, because they don't always
check their feeds.

Is the concern about namespaces in XHTML and what happens to
namespaced attributes in feed content when it comes to generating
syndication feeds?

Received on Wednesday, 18 November 2009 17:57:10 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:03 UTC