* 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 [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
