[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: document() question
I think you're doing the best that's possible within the constraints of the XSLT and JAXP specifications. If you're worried about magic constants, return <x:dummy xmlns:x="........"/> using a namespace URI based on a domain name that you control. That's considered respectable as a magic constant in the XML world. Mike Kay Software AG > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Joerg > Pietschmann > Sent: 05 July 2001 17:45 > To: XSL List > Subject: document() question > > > Hello all > > The spec for the document() function states: > "If there is an error retrieving the ressource, then the XSLT > processor > may signal an error; if it does not signal an error, it must recover > by returning an empty node set." > So far, so good. > I want to write a style sheet which retrieves some data from external > documents, however, i don't want the processor to signal an > error if the > ressource can not be found. Instead, i want to handle this in > the style > sheet. I tried to supply a somewhat twisted URIResolver to > the processor > (Saxon 6.3), but it seems i have to feed it some valid XML. I was > successful using a StringReader("<dummy/>"). This raises two problems: > - I have to test for two error conditions: document() may > return a node > set with the "dummy" element node in case the ressource was > not found, > and i have also to test for an empty node set in case something else > went wrong (for processors which don't raise errors). > - It violates the design principle of not to use magic constants. > > Question(s): Is there a way to write an URIResolver so that document() > will return an empty node set in some specific cases? > Is there a better, portable way to silence a processor about missing > ressources in invocations of the document() function? (Note: a "File > exists" extension function is not (yet) portable and in any > case subject > to subtle failures due to race conditions.) Or for some other error > conditions for that matter, like ressources not containing > well formed XML, > or missing external DTDs. > > Last Note: The XSLT 2.0 usage of document() for multiple > output has even > more failure modes than the applications for reading. This will become > *really* interesting. > > Regards > > J.Pietschmann > -- > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
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
|