Re: XML-based Help Authoring tools for customized help

[Sean Wheller <seanwhe -at- yahoo -dot- com>]

From: "Mark Baker"
> Sean, you keep putting XML in a little box, and in
so doing you make it
both
> more than it is and less than it is.

I don't mean to do so; promise:-)

We agree on most points.

> > XML is True Single-source and Frame is WYSIWYG.
>
> XML is not true single source (however you define
that). XML is a means
for
> designing tagging languages.
I'm at the application level here. When I used the
acronym XML my intent was
XML as an application for authoring and publishing.

> is. The enemy of single sourcing is not WYSIWYG, it
is document-oriented
> thinking.

Yes. This is very important. You mentioned it once
before in explaining
tools and applictions for one of the David's. The
focus is on content not on
documents.

>
> > The pradgim of authoring in a WYSIWYG environment
and then exporting to
> XML
> > is broken and in my option should not be employed
in any information
> > development cycle where XML is employed as the
storage format.
>
> Again, you are putting tools before process.
I thought we had gotten past the discussion on
process.
Bah! Email is a hard way to hold a conversation. IRC
is much better.

> > XML, as many
> > have already said, is for exchange.
>
> Again, no. What was said, if I remember correctly,
was that *standards*
are
> for exchange.

Hmm. The semantics again.
A standard is common protocol or a common
understanding that serves as a
single point of reference upon which clear
communication is based. XML is a
standard, no? One result of which is exchange. Can we
agree?

> XML is for designing tagging languages.

Yes. For describing data.

> You can also use things other than XML to define
standards and you can use
> XML to define things that are not standards and are
not used for exchange,
> but are still useful.

Yes, but let's not compound the situation.

> > The point of using XML in the
> > information development cycle is to avoid lock-in
at the presentation
> layer through the use of an open and standards based
format. This format
should
> be transformable to any presentation (formatted)
target.
>
> Again no, for all the reason stated above. What you
should say is that
*one*
> reason to use a document oriented markup language is
to avoid lock-in at
the
> presentation layer.

Sematics, I think my intention was clear.

> Sean, in all of your posts on this topic you seems
to be discussing a
single
> publishing system that happens to be based on XML
and then you sound as if
> you are claiming that:
>
> A: This publishing system is XML and that all the
virtues of XML are
present
> in this system.
> B: The virtues of this system can only be
implemented in XML and in no
other
> technology.
I have limited myself to "An XML autoring and
publishing system". With good
reason. The permutations of a less focused
conversation would not be
productive. I have not said that XML is the only
solution. I do advocate
that it is an extremely viable solution considering
the diverse applications
of content. I think it is the most neutral option.

It is easier to do so if you go back to XML as the
source for all content
storage.

> XML is a useful tool that can be deployed
> in many ways in many different kinds of publishing
systems. However, it is
> not the only way to implement any of those systems.

It is the base technology upon which as application is
built. That
application will impliment process.

> You don't get any
> publishing advantages just from the fact that you
are using XML.

I beg to differ.

> You have to
> implement a particular system to support a
particular process.

Yes. I am saying that with an XML foundation, the
content layer is
abstracted from the presentation and from the process.
Technology choice and
Presentation choice and Delivery Choice are no longer
factors that have the
potential to lock you in. This is a real winner.

> Your real win
> comes from correctly defining an efficient process
and successfully
> implementing a robust and usable system to support
that process.

That is a very generic statement. The problem is that
you must use a
foundation that is flexible enough to be used by any
system and that is
scalabile to adjust to any process.

>
> The only advantages you get just from the fact that
you are using XML are
> the software development advantages listed above.

Experience tells me otherwise. But we can agree to
disagree on that one. The
scope of this topic was originally set by Karen a few
days back. The subject
of XML was part of the topic. Karen wanted tools that
could achieve an aim.
I asked if she had considered Docbook, she never
responded. But everyone
else did and then things just spiraled into a very
interesting but sometimes
confusing mish-mash of all our thoughts, beliefs and
wishes.

I and others felt that Docbook would meet her
requirements. This has lead to
what I consider to be one of the most productive and
informative threads
that I have seen on this list for some time. I have
learnt things and
hopefully also taught things and that is what it is
all about.

Sean Wheller


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

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

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.