> On a document level, it's easy to be draconian. Simply don't provide > any xinclude:fallback elements. Then a missing resource will be > fatal. The current draft doesn't provide any means to implement this > at the parser level though. Back to "the only way to get sane behavior is to rely on non-standard extensions" evil. Chthulu is pleased! > This is all new functionality in the > recently released CR, so if you don't like this make a comment to the > working group. (Personally, I think anything as major as this should > require a return to working draft status. Stuff like this should not > be added at CR.) Agreed. On the other hand, if the XInclude spec said that you needed to substitute <xi:error code="..."/.>, rather than content found in the document, it'd at least start to make technical sense as a processor-neutral way to report errors ... even though it would still be polluting the data content of the document. One could imagine statements that documents with xi:error elements have no canonical form. - Dave
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format