Not quite. Since this is XSL that's at issue here:
1. Validation is irrelevant. XSLT processors don't validate.
2. DTD resolution is relevant. XSLT processors have to load the
external DTD to resolve entities and perhaps supply default attribute
values. The XPath 1.0 data model simply does not support unresolved
entity references.
3. I suppose an XSLT processor might defer loading the DTD until it
finds an entity reference it needs a definition for. But then how does
it handle default attribute values for previously processed elements?
Start over?
4. Some processors might just drop out unresolved entity references,
but I wouldn't trust any processors that did so. Someone may point
out that the XSLT spec doesn't actually define how the XSLT processor
gets its input tree from the source text. This has been used in the
past to support arbitrary mangling of the input document by an
allegedly conformant processor. You'll have to ask your XSLT vendor
how and when they mangle the input.
5. A catalog could be used to load the DTD locally from the public
identifier rather than the URL in the system identifier.
--
Elliotte Rusty Harold
elharo(_at_)ibiblio(_dot_)org
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--