Re: XML-based Help Authoring tools for customized help

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

From: "David Knopf"
> Well, that could be one point, I suppose, but for
most of the
> organization I've worked with, the real point is
getting work done and
> achieving specific business objectives in a
cost-effective way.

Exactly David, the application of XML in authoring and
publishing add value.

> Frame was born as a DTP tool but has grown to be a
content authoring tool.

But still the majority of the package is about DTP. To
me it seems that the
DTP aspect is redundant baggage during authoring.


> >from my perspective it is therefore concerned with
presentation. Authors
have also become partial to using Frame was word
processor. In my books
using Frame for the later purpose, in an XML
Publishing Tool Chain, defeats
the purpose of working in XML.

> You say this as if it were self-evident, but I do
not think it is.

To me it is. I cannot see the point of authoring
content in XML with a tool
that is largely a DTP tool. When I save a Frame file
to XML, I have no way
of saving the DTP. All I am saving is a semantic
description of the content.
Don't get me wrong. From what little I do know about
Frame, it has some
amiable qualities.

> Frame can do WYSIWYG. It can also do XML.

Yes but what was the point of using all that WYSIWYG
if when you save to XML
you cannot save the stylesheet to XSL.


> >Both are on opposite ends of the same stick. If you
try to bring them
> >together by bending the stick, it is bound to break
at some point.
>
> Perhaps, but it seems to be working rather well in
an awful lot of
> environments.

Yes and no. Not many environments use XML as their
primary format of
storage. The result is that they work, for example in
word or frame, and
store in the formats proprietry to those tools. These
tools save in a
formatted editing source that could be used directly
for print. They can
also save to other formatted output such as RTF, PDF,
HTML. The problem is
not however in moving to the various formatted
outputs. The problem is that
when a proprietry format is used to store content,
that other tools cannot
easily open and modify the content. To exchange
content, a duplicate of the
content must be made. This breaks the single-source
paradigm.

So while the current method of working, works rather
well in an awful lot of
environments, you will find that exchange of source
material between
environments is only easily achieved if all end-points
are using the same
tools. It is difficult to optimize content reuse of
source with proprietry
formats without breaking the single-source paradigm.

> Frame is just as WYSIOO as any other XML authoring
tool, despite the
> fact that it can also be WYSIWYG. WYSIOO, IMO,
describes the state of
> mind of the content author more than it does the
capabilities of a given
> editing tool. If you are using Frame to produce XML
that will be
> transformed for presentation in other, non-printed
media, you know
> perfectly well that what you are seeing in Frame is
not what the content
> users will see.

I think you are right about WYSIWOO being a state of
mind. However, unless I
understand wrong, when you work in frame the document
template is attached
and renders fonts, layout etc. If you were to print,
these properties would
be sent to the printer and finally seen on a page.
When you compare the
document on screen, they are practically identical.
This is not WYSIOO. The
content and the template are one on screen. With XML
authoring the content
is application independant. The template however, is
application specific
and is only applied at the time that content is
transformed to the required
application.

> >As WYSIWYG, Frame goes beyond the tension limit and
breaks the stick.
Epic is WYSIOO, in my school, this does not break the
stick and therefore is
an infinatley better option. Leading Document
Orientated XML Editors such as
Epic, XXE, XMetal, Morphon, and Syntext have all shown
that WYSIWOO is the
"best practice".
>
> Oh? Where and when did they show this?

The tools I have mentioned have been designed from the
ground up for the
purpose of creating document orientated XML. Tools
like Frame where not
designed for this purpose and have tried to accomodate
document orientated
XML.
As tools continue to emerge and develop we find that
the developers have
spent long hours on how to cater for the need of
authors to see layout
without breaking the stick. Time and again the result
is WYSIOO.

Earlier in this discussion we spoke about the
problems. I think Mark had a
point about how cognition is impacted when authors are
expected to
type+markup. However, over time this barrier is
overcome. The problem is
that most people do not have the time or patience to
overcome this problem.
The result is that they stay in WYSIWYG. This presents
a commercial delema
for the authors of new XML authoring tools. They need
people to buy their
tool or go bust. Yet they don't want to "break the
stick".

Even tools like AuthorIT only display One Option and
that is the option you
are seeing on screen. That option is for the purpose
of optimizing the
readability and usage of real-estate within the
editor. It has no baring on
what you will get when you transform to a formatted
output, not even print.

> >The pradgim of authoring in a WYSIWYG environment
and then exporting to
XML
> >is broken
>
> Broken in what way? If an author produces valid,
conformant XML that
> integrates well with other tools used in a given
tool chain, what in the
> world difference does it make if the XML itself
happens to have been
> generated by FrameMaker or, for that matter,
"written" in Notepad?

I say broken because I think that design is
inconsequential to the authoring
process. I cannot see the point of working in a
proprietry format and
application specific presentation layer, just to save
it to XML and lose all
presentation. Rather, I think it is better to work in
the content layer and
apply the presentation layer as it is required for
each of the presentation
applications. This is far more optimized and has the
benefit of not breaking
the single-source paradigm. Content src remains in XML
where it can be
easily reused and exchanged across disparate systems,
by a broad number of
applications including Content Management Systems
(CMS).

> >and in my option should not be employed in any
information development
cycle where XML is employed as the storage format.
XML, as many have already
said, is for exchange.
> Exchange is a purpose of XML, not the purpose of
XML.

The semantics-of-sematics, me thinks. My intention was
to say the purpose of
using XML for publishing is exchange. Exchange from
XML to Presentation
Format and between systems.
Quote from http://www.w3.org/xml :
"Extensible Markup Language (XML) is a simple, very
flexible text format
derived from SGML (ISO 8879). Originally designed to
meet the challenges of
large-scale electronic publishing, XML is also playing
an increasingly
important role in the exchange of a wide variety of
data on the Web and
elsewhere."

>
>
> >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.
> XML produced with FrameMaker uses an open and
standards-based format and
> is transformable to any presentation (formatted)
target.

Yes. I am not arguing that. Please, I think that Frame
is a great tool. I
just don't think that an authoring system that is
based on XML should use a
DTP tool as an editor. There is no point of working in
the presentation
layer when you are going to save to XML. If you are
not based on XML, then
great, use Frame and Frame only. When Frame format is
the format of choice
for content storage. Back to this. The point of having
XML as the storage
format within an XML authoring system is exchange.
Between disparate tools,
presentation formats, and systems.

To me Frame comes in for print publishing
applications.

> >I don't know much about Frame, so please correct me
if I am wrong. But I
> >understand that a Frame template cannot be saved as
an XSL that could be
> >used, by any XML Publishing Tool Chain, to
transform an XML to a
formatted
> >target such as HTML or XSL-FO.
>
> You are not wrong; FrameMaker does not produce XSL.
But why would you
> need it to? If FrameMaker is used as an XML producer
as part a larger
> "XML Publishing Tool Chain," XSL and transformations
are handled outside
> of FrameMaker, and FrameMaker is invisible to the
rest of the tool chain.

The XSL is an application specific stylesheet. If
working in Frame gives you
the design control, why not save that control to XSL
for use by tools. If
the application is to PDF, PS or RTF. Then why not
save all the prentation
you see on screen to an XSL that is capable of
transforming XML to XSL-FO.
The FO output when transformed to PDF, PS, or RTF will
be typeset in the
same way as it was in Frame (on-screen). Now other
tools can edit the XML
and input it, together with the XSL obtained by frame,
to a FO Processor.
This opens up some interesting options, such as server
side transformation
which is especially useful with CMS.

> FrameMaker's native file format is proprietary, but
FrameMaker is by no
> means limited to "defining or controlling the design
of content." In
> Structured FrameMaker, authors have no control over
design, formatting,
> and layout, but work only with document structure,
as defined in a DTD
> (and EDD) used in their publishing environment.
Content authored in
> Structured FrameMaker can be saved as valid,
conformant XML at any time.

Is what you see on screen is WYSIWYG. If so then frame
is just an
alternative to an XSL for FO applications. The Frame
environment is being
used to typeset.

> >Once a MIF is created and the layout, style etc are
defined, any change
to
> >the content source will require that the MIF be
modified in order to
> >compensate for those changes. Whereas with XSL the
transformation to the
> >presentation format dynamically compenates for
modifications of the
source.
>
> MIF is just a plain text representation of
FrameMaker's binary file
> format and is really beside the point here.
FrameMaker transparently
> exports to XML and imports from XML. You can
transform and otherwise
> manipulate the XML outside of FrameMaker using the
whatever tools and
> workflow you choose.

I'm not disputing that. See points above.

>
> In closing, I'll clarify that I am not suggesting
that FrameMaker
> represents *the* future of XML or that it is the
right tool for any
> particular project or organization. I am saying only
that FrameMaker is
> a viable solution for producing XML and is used to
great advantage in
> many organizations. There is no "religious" reason
to write off
> FrameMaker as one tool in an XML publishing
workflow.

Yo. I am not taking frame under the knife. It is a
very powerful tool. I
just think it is a waste to have to pay license for
every author in a
department who is using the tool as an editor. Rather
optimize across the
board. Use an XML Editor for authoring and then have
one or two frame
experts do the DTP for print applications. Let the
majority of your authors
and SME's edit in in an XML Editor such as XXE and
your more programmatic
SME's may even use emacs or oxygen. In my thinking,
let them use what every
tool they want. The power of Frame is a waste is
financial and operating
environment resources.

A single set of XSL's can be easily controlled and
used to output
consistently formatted content across the entire
enterprise.

Sean Wheller
Somebody once said: "The future is here, it's just not
widely distributed
yet."


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