John L. Clark wrote: > I noticed a brief mention that this change would be coming in the next > version, but I refrained from commenting at that time because I did not > understand the reason. It is situations such as this that might warrant > a little bit more design transparency with users, although there may be > good reasons for not doing this. > > On Mon, Nov 29, 2004 at 03:49:40PM +0100, Hussein Shafie wrote: > >> * XML catalogs are no longer used to resolve the >> locations found in the href attribute of >> xi:include. This is a functional regression >> but at least now the behavior of XXE is >> consistent. Previously, it was possible to use >> XML catalogs to resolve XIncludes but, in such >> case, Edit|Document Reference|Edit Referenced >> Document (among other things) did not work. > > > One of the goals of document authoring is to be able to assign documents > unique names and make reference to documents using these unique names, > thereby facilitating referential integrity. Because of this, I feel > obliged to push back against this change, and to encourage maturity in > those parts of the XXE architecture that deal with URI references. I > would be very interested in hearing more detail behind the problems that > the XXE team found to exist in this feature. > > If you have referenced a global URI from a document (either using > XIncludes or a language-specific mechanism such as the img element in > xhtml or the imagedata element in DocBook), then the situation breaks > down into cases. Either the URI can be resolved, or it can't. If it > can't be resolved, then it makes perfect sense to warn the user and > display placeholder content, such as that provided by xi:fallback when > using XIncludes. If it can be resolved, then it is either resolved > locally or remotely. If it is resolved locally, then the local > representation should be returned when examining the referencing > document as well as when choosing the Edit Referenced Document function. > If it is resolved remotely, then the referencing document could display > the included remote content. Should the user want to edit the > referenced document, XXE could negotiate with that user on whether or > not to save a local copy. Note that XML Catalogs could be used to > resolve either locally or remotely; the point is that the resolution > should take place not just for reading, but also for opening for edit. >
We agree on the usefulness of supporting XML catalogs to resolve the hrefs of XIncludes in the case of an XML Editor such as XXE. After your bug report, we have sincerely tried to implement this feature reliably and consistently everywhere where this should be done in XXE (example: "Edit Referenced Document" but also "Save As"). We simply failed to find a way to do that. When we added the support of modular documents in XXE, we have done that because we were hearing this from (non-technical) users: "OK, I have written a DocBook chapter. Now, how can I add it to a DocBook book?". Our answer was: use your favorite text editor to write a master document and reference your chapter as an external entity in the master document. We were of course *ashamed* to have to give such answer. The situation is the following: XMLmind XML Editor does not support XIncludes as a generic, powerful, include mechanism. XXE uses XIncludes as a simple, standard (by opposition to proprietary), mechanism to split large ``books'' into smaller, more comfortable to edit, ``chapters'' and ``sections''. And that's it. Nothing more ambitious than this...
