- From: Paul Prescod <paul@prescod.net>
- Date: Tue, 15 Jan 2002 09:33:41 -0800
- To: www-tag@w3.org, xml-dist-app@w3.org
Mark Baker wrote: > >.... > > It's a perfect example. This document is logically XSLT, not HTML. > > In this example, I'd say it's both HTML and XSLT. However, HTML has > the advantage in determining how that XSLT should be interpreted, since > it's the container. Let's put it this way. The XSLT fully defines the meaning of the document. In fact, this document was cut and pasted OUT of the XSLT specifications. That specification claims that it is XSLT. The XHTML specification, on the other hand, specifically says that such a document is not "a strictly conforming XHTML 1.0 document". So one specification claims the spec. is correct and describes how to process it. The other says it is "not strictly conforming" and says nothing about how to process it. > For example, if HTML had an element called "do-not-process" that meant > that any content whtin should not be dispatched to alternate processors, > and that your XSLT was within this element, would you still say it was a > stylesheet? Absolutely. And it isn't a matter of opinion. XSLT says nothing about the do-not-process element, therefore it would be invisible until after the XSLT parts had been processed. The HTML processor doesn't even see the content until after the XSLT processor is done with it. > I agree with TimBL when he says; > > "The significance of any nesting of one withing the other is to be defined by > the nesting (outermost) specification [...]" > > (from http://lists.w3.org/Archives/Public/www-tag/2002Jan/0081.html ) That's a good theory but there is at least one W3C spec that does not work that way. Perhaps it needs to be fixed. Paul Prescod
Received on Tuesday, 15 January 2002 12:38:02 UTC