From: Elliotte Rusty Harold <elharo@me...> - 2002-10-29 15:18:17
Putting aside for the moment the issue of whether saxon:warning is
namespace well-formed, I'd like to look at how saxon responds to
rootless output that is a well-formed external entity reference.
According to the extensibility docs:
When a ContentHandler is used, Saxon will by default always supply a
stream of events corresponding to a well-formed document. (The XSLT
specification also allows the output to be an external general parsed
entity.) If the result tree is not well-formed, Saxon will notify the
content handler of the fact by sending a processing instruction with the
name "saxon:warning" and the text "Output suppressed because it is not
well-formed". If the content handler is happy to accept output that is
not well-formed, it can respond to this processing instruction by
throwing a SAXException whose message text is "continue"; in this case
subsequent events will be notified whether or not they are well-formed.
Although I can work around this now that I've noticed it, this still
bothers me for several related reasons:
1. I may be wrong, but it seems to me this happens every time you use
TrAX/SAXResult to access Saxon to generate a rootless document becuase
in that case you always provide a ContentHandler. Is this accurate?
2. Since this is legal XSLT, I think the default should be not to stop
processing when it's encountered unless the user somehow configures
Saxon to do that. e.g. if the user sees the saxon:warning processing
instruction and wants to stop processing they shoudl throw the
exception. If they want to continue processing, they shouldn't have to
3. This adds an additional information item to the output that the
stylesheet has not requested. It's a PI so that's not too bad, but I'd
still prefer it not be there.
4. This is completely non-standard. Does Xalan do anything like this?
Does jd.xslt? I hate to clutter my engine independent code with special
cases like this to handle each XSLT processor.
I'm not sure there's a good way to handle this, but maybe passing this
info through setLocator() might be less jarring, especially if it did
not require any repsonse to continure normal processing. The document
locator does not represent an information item. Maybe a particualr kind
of locator object could be passed; e.g. RootlessLocator? thoughts?
Also, perhaps this is something that should be addressed for the next
iteration of TrAX.
Elliotte Rusty Harold