- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 01 Jun 2009 23:54:01 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6775 Jonas Sicking <jonas@sicking.cc> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas@sicking.cc --- Comment #7 from Jonas Sicking <jonas@sicking.cc> 2009-06-01 23:54:01 --- Just for the record, Firefox today uses a DOM-to-DOM transformation, i.e. we don't do any serialization. Once we have the result DOM, that is what we display. So if we didn't pay attention to the output method (as specified explicitly in xml:output, or using the implicit default mechanism), then all XSLT out there that generates HTML would in firefox be generating plain XML, which isn't what anyone wants. The alternative would be for us to output and then parse the output. But this seems like a expensive operation just to add HTML behavior to the result. I'm a little unclear on what the result of an XSLT transform is expected to yield. It doesn't seem entirely true that XSLT is an XML-to-XML transform since output (which is what generates the result XML serialization) is an optional (in XSLT 1) or at least external (in XSLT 2) step. And at least XSLT 1.0 talks about the result "tree", not the result "XML". I always thought of it as an infoset-to-infoset transform, in which case I'd have thought that the result infoset would contain the semantic information that we're dealing with HTML nodes. However, I haven't payed much attention to XSLT since XSLT 1.0, so I'm definitely not expressing a strong opinion here. And I totally agree that amending XSLT 1.0 is most likely a non-starter. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 1 June 2009 23:54:06 UTC