RE: [xsl] document() question

["Michael Kay" <mhkay at iclway dot co dot uk>]

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@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Joerg
> Pietschmann
> Sent: 05 July 2001 17:45
> To: XSL List
> Subject: [xsl] 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