Re: 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 not 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 document 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.
>

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support