Re: XML - specific questions
I found a very good overview of the subject in a PDF tutorial for XMLSpy, an
XML development environment (http://www.xmlspy.com/ - can't vouch for the
tool itself as yet) where I learned the meaning of "well-formed", "valid",
"schema" etc. I recommend it to all newcomers to the subject.
In my experience, XMLSpy has proven to be a very good editor for structured,
hierarchical data. It's not as well suited (compared against FrameMaker + SGML)
for text input.
1. If I have to produce a variety of documents - data sheets, user manuals,
protocols, release notes, etc. - does using XML mean that I can create these
on demand by simply selecting the relevant content chunks in each case and
specifying a suitable DTD?
Theoretically, with one change...it would be a different XSL, not DTD. A DTD,
like a schema (XSD, XDR) definition, specifies what elements and attributes
are allowed inside the XML document. An XSL (XML Style Sheet), on the other
hand, is used to transform (XSLT) or display (XSL proper) an XML document into
something that might be closer to a brochure, white-paper, etc.
You might, in fact, have different DTDs for the different document types
that you're translating into, but those just define what must/can be there.
It's the XSL/XSLT that translates from the source content XML into the
different presentations.
Unfortunately, we've found that it is quite difficult to write content
that will allow you to mix and match arbitrary content to fit the
different audiences implicit in the different vehicles you mentioned.
Not impossible, just difficult.
2. Am I right in thinking that XML can provide the means for a database of
modular chunks, retaining text formatting, para & char styles and bullets?
How practical is it to contain whole
chunks of documentation as database fields?
XML's main purpose in documentation is actually to completely remove the
formatting from the content. That is, the content is stored (in a database
if you want) with it's contextual information about what KIND of information
it is. For example, you might have elements that specify "topic", "abstract",
"introduction", "command-syntax", "section", and so on. The particular
interpretation of how the sections are displayed (rendered) should be handled
solely in the XSL transformation portion.
But, such things are never perfect. In general, the more the two (content
and presentation) are separated, the easier it is to use the content in
multiple presentations. The more presentation description that is kept in
the content, the more difficult it becomes to migrate it between presentations.
Storing it in a database versus in files is really pretty arbitrary. It depends on
how much time you have to build define the storage solution, how fine-grained
the chunks of XML will be, what version-control and access mechanisms you're
going to rely on. Database? File? It has more to do with that you're familiar
with and have at your disposal. After all, a file-system (with files an folders)
is just one type of database.
3. My preferred source tool is FrameMaker, but with a great deal of
checking, rechecking and signing off needed from SMEs who only have Word,
the problem of mutual incompatability is more acute than ever. I was
thinking of going down the route of saving as PDF then using Acrobat 5 to
convert this into RTF (the software's on order so can't say yet how well
that works), but given XML's rumoured databasing advantages, will XML be a
truly compelling alternative?
It depends on your mind set. If you're a doc/editing/writing person, XML will
stretch your brain. And yes, it will hurt at times. On the other hand, if you
can get your head around the idea separating content items from presentation,
then XML can be useful. That said, current authoring environments for structured
documents are not nearly as mature as they are with word processing or
document publishing packages. When you compare, say Frame to current (non-Frame)
XML authoring packages, think more like, say, WordStar, Notepad, or similar.
4. FrameMaker can save as XML (which looks authentic enough once you open
it), but how is this useful given that you can't define reusable schema
components and other tricks of a true XML editor? Is a dedicated XML editor
essential - or can FM+SGML do the trick (though SGML isn't really XML, and
only adds another step in the process)?
Again, it depends on the style of work. True XML editors, like XMLSpy is much
better at working with what amounts to structured data. Your data might be
chunks of text, but editing that in XMLSpy's advanced grid-view will be an
interesting exercise in paradigm shifting. Linear text? Not. XMetaL can do a
little better, but it is still not WYSIWYG.
Remember, XML is an SGML application. That is, SGML can define many different
markup languages. XML happens to be one of them. Heck, HTML is another
language that could be defined in SGML.
5. I've seen recommendations for "SGML - the Billion Dollar Secret" (which
applies to XML, too) and "Inside XML" - but are there any good books on the
subject of XML specifically for tech documentation? Most seem to be
oriented to programmers and web designers.
I think that's probably because XML really IS better suited to programmers
and Web designers. Why? Because the power of XML is that there is a single,
flexible and extensible language in which the structure and the content of
a set of data can be defined. In previous generations of system, there were
elaborate implicit or explicit contracts between systems that were designed
to exchange data. With XML, if the two communicating systems can "get to"
XML, then they can usually be made to communicate. Even if each system
puts out different XML, the XML transformation (XSLT and XSL) mechanisms
can be used to translate the messages between the systems.
We've been working in XML for over a year now, and have a wealth of
experiences, both good and bad with it. Here's the main difference I've
found. With Word, one moment you love it, the next you hate it. XML
is more flexible: at all times you both love and hate it. Tee hee....
Thom
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
Previous by Author:
Re: Tech Editing Books
Next by Author:
Re: Yet another odd Word question...
Previous by Thread:
XML - specific questions
Next by Thread:
doc management software: AM-Meridian
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads