Fair enough Hussein. Thank you for eliminating XXE as the source of the problem.
>________________________________ > From: Hussein Shafie <huss...@xmlmind.com> >To: Jeff Hooker <j...@itwriting.ca> >Cc: "'xmleditor-support@xmlmind.com'" <xmleditor-support@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 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@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
