RE: XML-based Help Authoring tools for customized help

["David Locke" <dlocke -at- texas -dot- net>]

Soap is middleware. Middleware traffics in both content and presentation.
The whole three-tier, client-server model is an architectural abstraction.
When we arrive at the point where content is a transactional good, an
XML-based standard will be agreed upon, whether or not that is DocBook
remains to be seen, because we haven't arrived at the transactional good
yet. XML by itself won't enable content as a transactional good by itself.
It just provides the infrastructure that will enable it.

Content management systems enforce the need for structured, non-linear
writing, not just structured markup. The skill is in the writing not the
markup. Non-linear content can be written successfully, but it can only be
done purposefully. It's not an after-the-fact, add-on. Given the grief I've
gotten over the years for writing non-linear content by other TWs, writing
non-linear text is not within the skill base of a lot of TWs.

The focus should be on the semantics. This focus takes care of the
presentation once you have designed your template to associate semantics and
presentation. The only reason WSYWIG would slow an author down is if they
ignored the semantics when they developed their templates. Semantic-based
markup is an integrative act.

Using the word formats when discussing XML is tied to XML Schema where the
focus is stuffing things into a database. Extended Backus-Naur form was a
language used to describe other languages that were then taken to a
compiler's parser. They are real languages, not formats. Formats were a
weaker tradition. Formats were the constraint overcome by markup languages.

XML is about data. When we talk about content, we are framing content as
blobs. A blob is the stuff of nothingness, semantically speaking. It is the
end of processing. A blob is text or graphics or who knows what. Specific
programs have to be designed to eat it. A markup tag only tells you what
program to associate with it. This is the same with forms and database
blobs, or the marked up content of a tag, any tag. The tag is metadata. The
tag increases the value of the data. But, only the container semantics is
intelligible.

To make an XML document into an application, you need a DOM, so you would
need XPath and XPointer. These are additional layers of the XML paradigm.
XSL is middleware and is not limited to presentation in the CSS sense. It is
the presence of forms and JavaScript, et.al. that make HTML into an
application. The raw markup is not an application. You might let transforms
turn it into an application.

XML makes data smarter, so the application code can be dumber. The problem
is that we don't have applications consuming our documentation, so the
driver for using XML is personal. Flexibility without purpose is what
exactly? Saying that, I would be the first person to say yes lets create an
XML centric process, but I'm not going to do it in Notepad. I'll use Frame,
or Robo, or Word, or DreamWeaver, because they save me time. And, no, money
spent on production will not kill the company, unless sales is killing the
company. Get your tools, make a larger install base, costs go to zero.

David Locke


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.  
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for 
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

---
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.