Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
|
