Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Open Source XML Editor
 From: Danny Ayers [mailto:danny@p...] <- True. But remember that when you make the DTD/Schema <- drive the editor, you may be mixing the data structures <- and the document structures (sure you can use XSLT to <- get around some of this). Some like this kind of <- editing, but the structures make a lot of difference. >On the one hand I'm tempted to say "what's the difference, XML is XML", but >being less pedantic I'd suggest that non-presentation stuff could easily be >hidden by the editor. Or the reverse. The issue here is context. What in the DTD/Schema provides a context for editing? A <p> or <td> or a <description> or a <partnumber>? When editing the kind of dense extremely detailed specific material in a tech manual, the content tagging produces a better context. So, hiding the presentation structures, or better, having a stylesheet works better. The trick is to adjust for the skill of the author in the domain. A skilled author sees the <partnumber> and knows what to enter or find. The less skilled author sees a table of items with a title and a table number. Or maybe, they are equally skilled with different roles: a tech writer for the first, a technical editor or layout artist for the second. <- DTDs that had to cover a family of documents produce <- bizarre complex editing paths. So the analysis is <- very important both in the lifecycle path of the <- information and the workflow of the production staff. <- Problems like this lead to a lot of the early thinking <- about enterprise wide markup systems. >Bizarre indeed. When XML is a little mature, and things like Schemas & RDF >start showing their potential, hopefully some of the mess will coalesce. No, it never does. It has to be planned and designed. That is what enterprise engineering is about. Looking at the data plumbing, the apps, and scheduling the flow of items into and out of types of events such that the product output is correct by construction, not only in structural terms, but in terms of the correct binding order and in accordance with the contract governed by the policies. The DTD/Schemas are easy. This sort of design typifies large multi-disciplines, possibly distributed projects. This is the kind of project the aerospace firms, the military industrialists, etc. do. The trick of SGML/XML was to get a lexical unification so the application of schemas, rules, stylesheets etc would work at all scales using virtually the same tools. <- Michael's examples reflect programming <- documentation. Of the types of technical information <- I've worked with, it is the easiest. The <- harder bits tended to be the hardware systems with <- the extensively indexed and cross-referenced drawings <- combined with repair and assembly. Software and the <- the software authors are a piece of cake by comparison. >That seems reasonable, but again I would think that the difference here is >likely to be reduced in coming years - after all, it's not difficult to view >a piece of hardware in OO terms. Perhaps, but is that really the view of a particular user in a particular context of time, space and directive? That is precisely the problem. The presentation is a view in a space/time/control system for real time events. Objects and objectisms (what David Durand called the "fairy dust of objects") don't solve all of the problems. Topic maps are really appropriate. Objects are just resources of a particular organization type. Topic maps are a means to organize types for navigation based on contexts external to say the system architecture of the documented item (eg, the hardware). One does NOT want to walk a system/subsystem tree to find a replaceable part. One wants a topic map or something like it to tell them in some context of a diagnostic precisely which part may cause a failure, then display the exact steps for removing and replacing the part, the exact tools needed, the exact order of further tests, and so on. It is also good if it can send a notification to the supply depot to ready additional parts. This isn't really hairy stuff; it isn't an easy book to write either. On the other hand, the technical writers and logisticians have been building manuals like this for much longer than even SGML has been around. <- What Alshuler missed as I recall was that many tech <- writers were stuck like tractors in a muddy bog by <- the writing standards they had been using. It was <- part of the problem of the 38784/28001 roadblocks <- put up to doing interactive technical manuals. They <- did not want to code the tags to begin with, then <- when they began, they immediately replicated all <- of the problems for which they were the owners <- of the solutions. So even if the markup was easy, <- the mindset was wrong. 38784/28001? Sorry, I don't get the reference. I do follow and agree with your point about the mindset though. Those are two mil standards for technical manuals. They are book metaphor, that is chapter/section etc and the appropriate table types. They take a long time to learn to build. The IETM alternative was 87269. It provides a system/subsystem breakdown, but also requires a view package for rendering. (Sorry, too much to explain here. Take a look at some CALS sites such as the Navy CALS web pages.) <- Today, the almost shocking thing is that <- so many of them won't give up WinHelp or WinHelp tools. >What's your feeling on JavaHelp? A similar source (HTML docs) and end >result, but indexed using XML so potentially possible to cross reference. We are MSThralls here. No Java. Sounds like a good notion though. <- Own the solution? Defend the problem. >I must remember to quote that elsewhere ;-) Or invent a problem to solve with a means you control. Life in a ricebowl. Controlling which means get chosen to control the means to solve a problem is how secret societies control the destiny of man. Ooops... now the Bilderburgers have to eliminate me too. (Gotta quit watching History's Mysteries while I edit...). Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h 
|
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
|
|||||||||
