I would like to make sure that all URL references in an xslt document exist. Extending URIResolver and pushing through a dummy xml document thru the xslt won't work because the xslt document contains select="document(url)" statements embedded in conditionals. What I am thinking is that I need to gather up all "select" attributes with calls to "document", however I am not proficient in XSLT. I know how to gather up the attributes (select="//[@select") but not partial (ie. select="//[@select="document......not sure). I know there is a better way to do this.
I think you need to apply the principles of TDD (Test Driven Development) to this problem. If the dummy XML document isn't a sufficient test, then you should create more XML documents which test the various parts of your transformation. Textual analysis is not a substitute for proper testing.
The xslt is very complex. Capturing all conditions by generating xml documents isn't efficient. Is there a way to load the xslt into the parse engine and then instruct the engine (saxon) to preprocess all referenced documents (all imports, includes and document() calls)? I guess I could create an xslt that does this.
If you are using Saxon, it would support well xslt 2.0 specific functionality. An xml document, basically and largely (except possibly borderline cases) is a text file. Hence, you can use the xslt function unparsed-text-available(uri) to verify availability of the external xml, characterised by a uri. If it is available, you do a select with document(uri)...
Suppose the call to document() appears in this case, say, and that the uri is stored in a variable or parameter named uri and that you select its data tags.
In that case you change a bit to verify the availability of it.
And somewhere there is supposed to having a corresponding template(s) to do the work on data elements.
It is not fool-proved, but it is functioning with detail to take care of...
If you want to check available inside the application rather than in the xslt document, you sure can do a match for all @select and parse the contain as text for the trace of evidence of document(...) with all the freedom of space between "t" and "(" etc.... like all the text parsing. Just have to do it that's all amid looked clumsy but necessary. But the reference to uri may be very indirect (such as in the above case the value being kept in a variable and you have in turn fetch for that variable... you can imagine the delicacy), the external parsing may not be as obvious as it sounds.
Oh sure, it's a tiny ad, but under the right circumstances, it gets bigger.
a bit of art, as a gift, that will fit in a stocking