Re: XML-appropriate editing data structures
On Fri, 2004-04-09 at 01:46, Elliotte Rusty Harold wrote: > > Because it is very common to need to create, either temporarily or > permanently, invalid content. For instance, when I was writing > Processing XML with Java in DocBook I typed many xinclude:include > elements that were not provided for by the DocBook DTD. In other > cases I've added custom elements and attributes that are not supplied > by the DTD. So, what if a company has 150 authors, and each of those authors are allowed to implement their own "useful" tag sets? Allowing authors to add tags not supported by the DTD (and therefore not by the processing systems that are designed to support what the DTD supports, nothing less, nothing more) renders the use of XML meaningless. There are enough problems getting authors to use what the DTD does provide in a correct manner. The tools I work with keep tags and structure in tight rein, which I am grateful for. However, I can provide another example of the consequences of tag abuse: Not too long ago I encountered a case where an author was supposed to use a procedure structure that looked a bit like this: <!ELEMENT procedure ((p|list|table)*, (step|bridge)*)> The author promptly proceeded to write a procedure like this: <procedure> <list> <p>...</p> <item>...</item> <item>...</item> ... </list> </procedure> One consequence was that instead of writing procedure steps with illustrations like this: <step> <figure>...</figure> <p>...</p> </step> the author wrote them like this: <bridge> <figure>...</figure> </bridge> <item>...</item> Imagine the consequences when steps are supposed to be reusable in a DMS, or the formatting rules require a two column layout for procedure steps with images to the left and text to the right. This document contained lots of other markup horrors, too many to list. The document wasn't authored by this writer alone, but instead of correcting the mistakes, others started participating in the insanity. The document was then reviewed, and passed because the reviewers "don't like to look at tags". Following the review, the document was sent to translation, so the markup errors were propagated from the DMS to the translation database. If we had not caught it when we did (which was entirely by chance) this document, and others like it, could cause serious production delays. The cost could run into millions of Euros. (The document cannot be formatted for printing properly. It is also likely that it will mess up an online help system. Using it as is, is simply not an option.) If the authors had been allowed to invent their own tags as they go along, the problems could get even worse... Of course I realize that when you insert an XInclude tag, you know what you are doing, but XML editors should not be targeted primarily at XML experts, they should be targeted at writers. Most would not know XInclude from dexitroboping, and there is no reason they should. (Unless they have to write about dexitroboping.) In an industrial setting the thing to do would be to modify the Docbook DTD, so that it contains the xinclude element. That is also the solution I would choose if I were writing something for personal use. That way I can have the editor assist me with the xinclude element just as with the Docbook elements. If I use the xinclude element more than once, it is worth the effort. If it really was a one time thing, I might have included the element in the internal DTD subset. More likely, I would have tried to find a workaround, not using xinclude at all. > > And in other cases, I do want valid markup. I just don't want it yet. > I'm not ready to fill in everything that's required. For instance, I > might begin a book by typing out an outline as section titles, > without actually giving the sections any content, though that is > ultimately required. But I can probably put together an outline in > day, even though filling in the content may take a year, as long as > the editor doesn't keep bugging me about the missing parts. But that is not really an editor problem. It happens only if you have a bad authoring DTD. I have seen authoring systems built around production or exchange DTDs several times. It is never pretty. As for Docbook, it is meant to be customized, and including an xinclude element in an authoring or production version of Docbook would be quite ok, even though it shouldn't be done in an exchange version. (Well, generally speaking. I can imagine exceptions.) > > I've tried editors that attempt to maintain validity. And they're > just bloody annoying. Even if you want valid markup, they're either > pestering you with pop-ups; or filling in what they think you'll add > and guessing wrong. (There's often more than one possible child > element that can be added to make a parent element valid.) Bottom > line: they get in your way. They are not smart enough to figure out > what needs to be done, but they do something anyway. That is not the editor either. It is the customizations are wrong. I have been in the same situation myself, but never because of the editor (not since I stopped using WordPerfect anyway). The problem is with the DTD, the customizations, or (all too frequently) both. An XML editor isn't a complete, ready-to-use-out-of-the-box authoring solution. It is a platform for developing a customized authoring environment. Not implementing a certain feature in the platform would certainly prevent abuse, but it would also prevent correct use. Personally, I would prefer giving authors more latitude than most industrial authoring systems do, but to do that, the authors must be educated about how to write structured documents, and about XML. Also, good review policies must be in place. So far, I have only seen one company that has even come close to doing that. /Henrik
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format