- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 23 Aug 2006 12:46:12 -0700
- To: mark.birbeck@x-port.net
- Cc: public-appformats@w3.org
On 8/23/06, Mark Birbeck <mark.birbeck@x-port.net> wrote: > > (And to answer Ian's question as to why you might want to have such an > XSLT file--how about a transform for creating XBL from HTC?) HTC isn't XML, so it's not clear to me how this would work. Even if it was, e.g. if you were converting RCC to XBL, XSLT still wouldn't be a sane way of doing it. And even if it was sane, there would still never be a problem, because you wouldn't ever point an XBL UA at the XSLT stylesheet containing the XBL in a way that the XBL UA would be looking for bindings. And even if you did, there wouldn't be a problem, because the fact that the document is XSLT instead of XBL would cause any number of parts of the binding to be flagged as in error and ignored, so there'd be no little or no harm done. And even in the extremely unlikely case of an XBL UA being given an XSLT document containing XBL that _isn't_ in error and attempting to display some content in it, the worst that could happen is that the document doesn't make much sense. Which is exactly what happens today if you look at an XSLT document which has, say, XHTML in it. I would assume that the XSLT spec would say that if its attributes were present on a root element, indicating that the document was really a transformation sheet, the semantics of those elements would be neutered, anyway. Does XSLT not say this? And finally, despite all this, note that this doesn't suggest XBL needs a MIME type, since XSLT already has a MIME type, and thus you can already distinguish XSLT from XBL. But if people really want to register a MIME type for XBL, go ahead... it doesn't affect the spec or UA compliance in any way. Feel tree to register as many types as you like. :-) -- Ian Hickson
Received on Wednesday, 23 August 2006 19:46:20 UTC