> I'm sorry but I cannot reproduce this problem, at least when I use dita.setConref normally.
Hmm. I've double-checked and I can reproduce with the out-of-the-box addon. Again, my steps to reproduce were: 1. Open a file with an existing conref. 2. Select the conref source element and press F2 Shift+V 3. Use the file chooser dialog to choose a different target file. 4. Click OK. (The new content is transcluded.) 5. Save and close the file. 6. Reopen the file. (The old content appears because the original conref path is still there.) > When you use dita.setConref, please always pass it an *URL* (absolute or relative) and never a filename. If you use [clipboard], the clipboard must contain an URL (absolute or relative) and never a filename. The file path examples (c:\xxx\xxx.xml) I gave are not what I'm entering manually into the dialog; they're just for illustration of the relative file locations. I'm using your file chooser dialog to point to my conref targets. > I understand but the rationale is: you have already chosen a conref *target* in this directory, therefore there are chances that you choose the new conref target from the same directory. I think it's great that you can choose another conref target from the same directory (ie, the file chooser remembers your last location). I just think the Set conref dialog should display the path in relation to the conref source, not in relation to the last target. -----Original Message----- From: Hussein Shafie [mailto:[email protected]] Sent: Monday, August 14, 2006 2:05 AM To: Mark Fletcher Cc: xmleditor-support at xmlmind.com Subject: Re: [XXE] dita.setConref changes not being persisted, and bad relative paths generated Mark Fletcher wrote: > When I use dita.setConref on an existing conref, specify a new url and > save the file, the change is not persisted (although the new content > is transcluded after changing the @conref). At first I thought I had > broken something, but I've reverted back to the original addon and I > can still reproduce. The workaround is to first call dita.setConref > [unset], then call dita.setConref. I'm sorry but I cannot reproduce this problem, at least when I use dita.setConref normally. > > Another problem I'm having is that the relative paths generated by > dita.setConref include a root drive letter. Here's my scenario: > > source file is c:\private\file_1.xml > > I use dita.setConref and map a conref to c:\user_doc\topics\file_2.xml XXE thinks "c:\user_doc\topics\file_2.xml" is a relative URL, while it is an absolute path name. When you use dita.setConref, please always pass it an *URL* (absolute or relative) and never a filename. If you use [clipboard], the clipboard must contain an URL (absolute or relative) and never a filename. > The resulting conref url looks like this: > ../../c:/user_doc/topics/file_2.xml > > While this path is technically accurate (XXE can find and transclude > the file), the climb above root and back down is unneccessary, and the > toolkit is choking on it. When I convert file_1.xml, it throws this error: > > [pipeline] [DOTJ013E][ERROR] Failed to parse the referenced file > '..\..\C:\user_doc\topics\file_2.xml' due to below exception. Please > correct the reference base on the exception message. > [pipeline] java.io.FileNotFoundException: > c:\private\..\..\C:\user_doc\topics\file_2.xml (The filename, > directory name, or volume label syntax is incorrect) > > The resulting conref should look like this: > ../user_doc/topics/file_2.xml And if I set the conref url manually to > this path, the toolkit processes the file without a problem. > An URL, not a filename, please... > The last issue I see is that the relative path context reported in the > Set conref dialog ("If path is a relative path, it is relative to > [context_path]") varies. If there is no pre-existing conref, the > context path is the location of the current document. But when you > change an exsting conref, the context path is the path to the current > conref target. The resulting conref path ends up correct, regardless > (well, except for the problem above), but I think its confusing to the > user that the context path is not always simply the path to the > current > (source) document. I understand but the rationale is: you have already chosen a conref *target* in this directory, therefore there are chances that you choose the new conref target from the same directory. Note that: * The recommended, safest way to use dita.setConref is by using the copy/paste paradigm (F2 c then F2 v). The "Set conref" dialog has been developped for completeness (debug, advanced users, very special cases, etc). It is not meant to be used by the average user. * If the "Set conref" dialog is to be used, tell your users to use the file chooser available from this dialog box and tell them never to type a path by hand.
