From kde-core-devel Fri Aug 14 12:44:31 2009 From: Michael Leupold Date: Fri, 14 Aug 2009 12:44:31 +0000 To: kde-core-devel Subject: Re: Changing the default application associated with application/xml Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125025536708689 David Faure wrote: > On Friday 14 August 2009, Michael Leupold wrote: >> David Faure wrote: >> > On Tuesday 28 July 2009, Raphael Kubo da Costa wrote: >> >> I'm not sure if this should actually be taken to kde-devel; if so, >> >> please tell me. >> >> >> >> Bug 201162 (https://bugs.kde.org/201162) isn't actually a bug - the >> >> default application associated with XML files is Konqueror, but when >> >> the XML file isn't styled it just renders a blank page, confusing the >> >> users. >> > >> > Interesting, both khtml and kdewebkit render a blank page indeed. >> > I was hoping webkit fixed that; guess not. >> > >> > So I agree, real xml files could go to kate. But make sure that the >> > xhtml subtype keeps going to konqueror. >> >> Is this actually possible to decide before deciding on the KPart? >> According to http://www.w3.org/TR/xhtml-media-types/ you can't decide on >> the mime-type alone as XHTML documents MAY be served using >> application/xml or text/xml in addition to the proper >> application/xhtml+xml. > > If you follow a link to an application/xml page in konqueror, the new page > will still be shown inside konqueror, since the current part supports the > mimetype. > > But indeed, this means that typing a http URL in krunner could end up > opening up the page in kate rather than konqueror. Bad. > > I have no idea why they said that xkhtml documents may be served using > application/xml, that's just broken since it means we can't differ between > "xml that contains html tags" and "pure xml that a browser cannot > understand"... Yes, I fully agree on that. I'm currently contemplating writing a KXmlPart that can display xsl styled XML. The main problem I'll be facing is that given the current state I'll have to scout the XML and see if it's actually xhtml in order to pass it to an embedded KPart for the application/xhtml+xml mimetype. I don't know if there's any way we can fix it. There are several ways a browser could handle it but I can't judge if they make to implement for KDE: - Advanced document type detection using more than just the headers/mimetype - Giving KParts the possibility to "reject" a document so the application can pass it to the next part supporting the mime-type. This seems unrealistic as advanced KParts reimplement openUrl. I also guess this might have to be implemented on a per-application basis. Oh boy.. my regards to the respective W3C working group.. Michael