Alan Houser wrote: > Organizations are "successful" when they meet their business > requirements as efficiently (time and $$$) as possible. I talk lots of > people _out_ of migrating to XML for this reason. I even occasionally > say "you're doing just fine with MS Word."
Perhaps our roles are one of the reasons that ours views differ. My role is typically to make migration efficient for companies that have some committment to going to XML in the first place, so I do very few "Word vs. XML" deliberations. > If you're migrating to XML, *not* using FrameMaker, and have print/PDF > as one of your output requirements, take a good hard look at using or > leveraging a standard information model, like DocBook or DITA. Printing > XML using XSL-FO is one of the most difficult tasks you will face, and > leveraging the XSLT transforms for an off-the-shelf DTD is likely to > save a very substantial amount of development time. Creating XSL-FO is easy - I just tell a programmer what I want. Before you dismiss that as glib consider an alternative approach - say, using Perl to convert the XML to RTF. Either of these approaches are tasks for a programmer and using appropriate resources is at least as important as using the right structure. This should be apparent - you can be pretty sure that the people who wrote the XSL for the OTS schemas were programmers, not writers. Also, XSL-FO is typically used when the print process is a terminal use of the data. If that's all you need, then another approach is to convert the XML into another structure that is more Frame-friendly. There are ways of making publishing the data less difficult. > By the way, I never recommend starting out with out-of-the-box DocBook > -- if you use DocBook, I always favor constraining it. My observation > comes from a couple of implementations in which the client said "no > thanks, we're not going to bother constraining DocBook." Those clients > were creating fairly homogeneous information deliverables, and it turned > out that the writers were far more successful at marking up these > deliverables than I had expected, because they did so by example. Just > an observation. They may have been equally successful, but they weren't *more* successful than if the structure was more concise, so what did they gain? As far as I can see, they saved the cost of cutting it down at the expense of increasing the complexity of adding new writers needing to mark up by example. I'd suggest that's a pretty poor decision. > It's also important to remember that a DTD alone isn't sufficient to > structure your data. A DTD cannot specify all possible constraints (the > recent "nesting level" discussion is just one example), nor can it > prevent the use of valid but semantically-incorrect tags. There always > needs to be a human element for markup review and quality control. There are ways of dealing with issues like nesting, but overall I agree - humans need to play a role. Unfortunately, it's mostly to catch the mistakes made by other humans... ;-) Marcus _______________________________________________ You are currently subscribed to Framers as [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.