Re: [FrameSGML]

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Mark Barratt wrote:

> The logic is good. The problem is, as you say, where to draw the line. I
> think my primary skills - like a lot of Frame users - are as a writer
> and - like not so many - as a typographic designer. I use Frame to make
> documents for paper and screen which are fit for purpose. Inevitably and
> increasingly, that means understanding and controlling the way the
> software behaves, which means in turn knowing some stuff that seems to
> me esoteric and complex.

Absolutely, and that trend is likely to continue. I am of the opinion that
the role of technical communicator (or whatever you want to call it) is fast
becoming the stage where they are being relied on excessively for technical
decisions. I'm convinced that writers being forced to understand too much
about the upstream and/or downstream uses of the data will inevitably result
in some projects being thoroughly messed up - that's less a reflection on
the writers than it is on the project managers.

Implementing SGML formalised a methodology that writers already understood -
the concept of applying a consistent structure to a set of documents is
nothing new. Assembling documents from various sources and having fragments
of documentation contribute to the codeset of the product are much less
familiar, yet the technical communicator is being charged with these tasks
for the sole reason that in many cases, they control the DTD. The natural
extension of that is to rely on the technical communicator to fulfill the
same role as an organisation moves toward XML, but XML is about much more
than SGML has traditionally been used for. (Although SGML is capable of
being used as the syntax of B2B, B2C, application data exchange, etc, it
will not be used in that role. XML will.)

> That's OK: documents and media are complicated, and making them work for
> the user is what I do. But I'm not a programmer, and the bar for people
> like me to dealing with 'real' software is pretty high. A chance
> encounter in the (astonishingly good, IMHO) FM+SGML Developer's Guide
> with a reference to a number being expressed 'in C syntax' led to a
> half-hour of panicky research. I have *no idea* how 'C' works.

And you're right to ask the question as to whether you should. Perhaps the
real problem is that you're being insufficiently supported by your IT team.
Don't take this stuff on lightly - some of it is very difficult for anyone
to get their head around, let alone someone who already has a full-time job.

> I can deal with the kind of 'programming' represented by the Frame
> read/write rules or by bending EDDs to my will. The interfaces are
> beautifully designed and extremely well-documented.

As Lynne Price points out, you're already a programmer to some extent, but I
don't agree with her implied conclusion that you do ultimately need to know
how to program with the FDK. (Unless I have misunderstood what she said - if
so, my apologies, Lynne.)

> Specific question: what's the FDK learning curve like for someone like
> me?

That depends on you, the support around you, the project, the weather... If
you've got a programmer around, they will learn it more quickly than you
will. If they can't, you've got a broken programmer. :-)

> General question: how could the power of Frame be made more readily
> accessible to document designers?

By familiarising your IT department with Frame's substantial capability. The
sooner you start including your IT department on document design, the sooner
all these problems go away. Have a look at the overall complexity of XML and
all of the related recommendations and you will quickly realise that at some
point in time you're going to have to step back and get a programmer
involved anyway - I would start thinking about doing so sooner rather than
later.

Please no flames from technical communicators - if you think that I'm
suggesting that as a group you're incompetent, you haven't read closely
enough. I sympathise with you and see problems on the horizon - that's all.
The creation and management of data is a changing dynamic, and you're going
to get the blame if things start to come unravelled.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **