From: Hussein Shafie <hussein <at> xmlmind.com>
To: Jeff Hooker <jeff <at> itwriting.ca>
Cc: "'xmleditor-support <at> xmlmind.com'" <xmleditor-support <at> xmlmind.com>
Sent: Tuesday, March 20, 2012 1:44:07 AM
Subject: Re: [XXE] Document Cache in XXE 5.1.0 behaving inappropriately

* By following the procedure 1.2.3. you describe, I cannot reproduce the problem using XXE v5.1 and our WebDAV plug-in talking to Apache httpd+mod_dav. Note that we have really used 2 different users and 2 different machines during our test.

* We do not see how what you describe could be technically possible using XXE out of the box.

* We, XMLmind, do not provide any support for Bluestream XDocs. We are not affiliated to Bluestream. We never refer to Bluestream XDocs anywhere in our Web site.

* Unless you explain us how to reproduce this problem using XXE v5.2[*] alone or with any add-ons developed by XMLmind, please do n ot bother sending further support requests to the mailing list. This policy is clearly stated here:

http://www.xmlmind.com/xmleditor/support.html#xmleditor_support_policy

Besides, you are not a direct customer of XMLmind. (You are probably using the XXE bundled with Bluestream XDocs.) Therefore we have no obligation to provide you with support of any kind.



---
[*] Notice v5.2. We'll not accept a bug report for v5.1. You are supposed to test the latest release.

Note that v5.2 adds a workaround a Java bug which *may* explain the problem you have. However this is unlikely as we were not able to reproduce your issue with v5.1.



---
PS:

What follows can happen but is not a bug and we won't fix it:

1. User 1 opens a docbook XML docume nt containing one or more xincludes.
The xinclude content is displayed in the document.

2. User 1 opens the content of one of the xincludes but forgets about it.

3. User 2 opens the content of the same xinclude on another computer,
edits it, and checks it in.

4. User 1 uses CTRL-SHIFT-E to switch the xinclude for editing. It's indeed the outdated xinclude.

Why not a bug? Well, 1.2.3.4. cannot happen when file locking is enabled. At step 3. User 2 is warned that the xinclude is locked by User 1 and that she/he cannot edit it.



On 03/19/2012 11:14 PM, Jeff Hooker wrote:
> Unfortunately, the issue is not fixed after all.
>
> It still persists, even in the native XXE docbook5 plugin, when the
> following conditions are met:
>
> 1. User 1 opens a docbook XML document containing one or more xincludes.
> The xinclude content is displayed in the document.
> 2. User 2 opens the content of one of the xincludes on another computer,
> edits it, and checks it in.
> 3. User 1 uses CTRL-SHIFT-E to open the xinclude for editing. At that
> point, regardless of the document cache setting, XXE will open the
> outdated document. It must be emphasized that the *correct* version of
> the document is loaded into the computer's local cache, but it is not
> opened by XXE.

What local cache? XXE does not open documents previously stored in a local cache.



> 4. When the user edits, saves, and closes the document, the outdated
> version of the content is saved to the repository.
>
> Clearing the XXE cache does not clear the outdated content; restarting
> XXE does.
>


On 03/19/2012 11:14 PM, Jeff Hooker wrote:
> Additional details:
>
> 1. This happens only when using the Bluestream XDocs VDrive. I am not set up to test it with any other virtual filesystem.
> 2. Re-opening the outdated file from within XXE using File > Open > [filename].xml opens the correct version of the document from the repository.
>
> If we could pin down the difference between using CRTL-SHIFT-E to open and Xinclude and File > Open > [filename].xml, we'd have good idea of where the problem resides.
>

There is no difference between CRTL-SHIFT-E and File|Open other than CRTL-SHIFT-E does not show a file chooser dialog box.



On 03/19/2012 11:14 PM, Jeff Hooker wrote:
> I've now duplicated the issue in DITA with conrefs. Other than substituting conrefs for xincludes, the workflow is identical.
>