John L. Clark wrote: > Simply, I have an XSLT transformation which, when called on a DocBook > file from the command line (`xsltproc > ~/.xxe2/config/docbook/xsl/change.xsl docbook-file.xml`) produces the > expected value, but when used from an XXE configuration, adds a tiny bit > of data in an unexpected way. In particular, the fileref attributes of > imagedata elements have the text "./" added at the beginning. I just > wanted to know where this data comes from. Of course, this fileref does > specify a URL location, but I don't know that there is any way for XXE > to know that a priori (as it is not specified anywhere in my > configuration). > > Does this have anything to do with the cfg:documentResources element of > the parent configuration? How does this element affect transformations? > How can such potential behavior be controlled? > > I have attached the zip file of the user configuration (as if it were to > be unzipped directly into ~/.xxe2/config/) for your perusal if needed. > My initial test document is proprietary; I can generate a generic test > document if necessary.
Your process commands often contain: --- <cfg:copyDocument to="in.xml"/> --- This is in fact equivalent to: --- <cfg:copyDocument to="in.xml"> <resources match="(https|http|ftp)://.*" /> <resources match=".+" copyTo="." /> </cfg:copyDocument> --- See http://www.xmlmind.com/xmleditor/_distrib/docs/poweruser/ar01s04s02.html#process And that's true, the resources which are logically part of the document are specified using another configuration element, <cfg:documentResources>, found in the parent configuration (i.e. <cfg:include location="docbook/docbook.xxe" system="true"/>): --- <cfg:documentResources xmlns=""> <cfg:resource path="//@fileref" /> </cfg:documentResources> --- Therefore, if you need the *simple* behavior, expected when specifying this *simple* copyDocument element: --- <cfg:copyDocument to="in.xml"/> --- You need in fact to specify this *complex* element: --- <cfg:copyDocument to="in.xml"> <resources match=".*" /> </cfg:copyDocument> --- in order to override the default behavior. Hum, hum, hum, may be there is a design problem here...
