File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes XML and Related Technologies and the fly likes Analyze document() calls Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » XML and Related Technologies
Bookmark "Analyze document() calls " Watch "Analyze document() calls " New topic

Analyze document() calls

Robert Harvey

Joined: Nov 18, 2011
Posts: 8
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.

Thanks for your help,
Paul Clapham

Joined: Oct 14, 2005
Posts: 19973

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.
Robert Harvey

Joined: Nov 18, 2011
Posts: 8
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.
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 632
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.
I agree. Here's the link:
subject: Analyze document() calls
It's not a secret anymore!