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.
