[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open Source XML Editor
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Danny Ayers <email@example.com>, firstname.lastname@example.org
- Date: Tue, 13 Feb 2001 12:29:24 -0600
From: Danny Ayers [mailto:email@example.com]
<- True. But remember that when you make the DTD/Schema
<- drive the editor, you may be mixing the data structures
<- and the document structures (sure you can use XSLT to
<- get around some of this). Some like this kind of
<- editing, but the structures make a lot of difference.
>On the one hand I'm tempted to say "what's the difference, XML is XML", but
>being less pedantic I'd suggest that non-presentation stuff could easily be
>hidden by the editor.
Or the reverse. The issue here is context. What in the DTD/Schema
provides a context for editing? A <p> or <td> or a <description> or a
<partnumber>? When editing the kind of dense extremely detailed
specific material in a tech manual, the content tagging produces
a better context. So, hiding the presentation structures, or
better, having a stylesheet works better. The trick is to adjust
for the skill of the author in the domain. A skilled author
sees the <partnumber> and knows what to enter or find. The
less skilled author sees a table of items with a title and
a table number. Or maybe, they are equally skilled with
different roles: a tech writer for the first, a technical
editor or layout artist for the second.
<- DTDs that had to cover a family of documents produce
<- bizarre complex editing paths. So the analysis is
<- very important both in the lifecycle path of the
<- information and the workflow of the production staff.
<- Problems like this lead to a lot of the early thinking
<- about enterprise wide markup systems.
>Bizarre indeed. When XML is a little mature, and things like Schemas & RDF
>start showing their potential, hopefully some of the mess will coalesce.
No, it never does. It has to be planned and designed. That is
what enterprise engineering is about. Looking at the data
plumbing, the apps, and scheduling the flow of items into and
out of types of events such that the product output is correct
by construction, not only in structural terms, but in terms
of the correct binding order and in accordance with the contract
governed by the policies. The DTD/Schemas are easy. This sort
of design typifies large multi-disciplines, possibly distributed
projects. This is the kind of project the aerospace firms,
the military industrialists, etc. do. The trick of SGML/XML
was to get a lexical unification so the application of schemas,
rules, stylesheets etc would work at all scales using virtually
the same tools.
<- Michael's examples reflect programming
<- documentation. Of the types of technical information
<- I've worked with, it is the easiest. The
<- harder bits tended to be the hardware systems with
<- the extensively indexed and cross-referenced drawings
<- combined with repair and assembly. Software and the
<- the software authors are a piece of cake by comparison.
>That seems reasonable, but again I would think that the difference here is
>likely to be reduced in coming years - after all, it's not difficult to
>a piece of hardware in OO terms.
Perhaps, but is that really the view of a particular user in
a particular context of time, space and directive? That is precisely
the problem. The presentation is a view in a space/time/control
system for real time events. Objects and objectisms (what David Durand
called the "fairy dust of objects") don't solve all of the
problems. Topic maps are really appropriate. Objects are
just resources of a particular organization type. Topic maps
are a means to organize types for navigation based on contexts
external to say the system architecture of the documented
item (eg, the hardware). One does NOT want to walk a
system/subsystem tree to find a replaceable part. One
wants a topic map or something like it to tell them in
some context of a diagnostic precisely which part may
cause a failure, then display the exact steps for removing
and replacing the part, the exact tools needed, the exact
order of further tests, and so on. It is also good if it
can send a notification to the supply depot to ready additional
parts. This isn't really hairy stuff; it isn't an easy
book to write either. On the other hand, the technical
writers and logisticians have been building manuals like
this for much longer than even SGML has been around.
<- What Alshuler missed as I recall was that many tech
<- writers were stuck like tractors in a muddy bog by
<- the writing standards they had been using. It was
<- part of the problem of the 38784/28001 roadblocks
<- put up to doing interactive technical manuals. They
<- did not want to code the tags to begin with, then
<- when they began, they immediately replicated all
<- of the problems for which they were the owners
<- of the solutions. So even if the markup was easy,
<- the mindset was wrong.
38784/28001? Sorry, I don't get the reference. I do follow and agree with
your point about the mindset though.
Those are two mil standards for technical manuals. They are
book metaphor, that is chapter/section etc and the appropriate
table types. They take a long time to learn to build. The
IETM alternative was 87269. It provides a system/subsystem
breakdown, but also requires a view package for rendering.
(Sorry, too much to explain here. Take a look at some
CALS sites such as the Navy CALS web pages.)
<- Today, the almost shocking thing is that
<- so many of them won't give up WinHelp or WinHelp tools.
>What's your feeling on JavaHelp? A similar source (HTML docs) and end
>result, but indexed using XML so potentially possible to cross reference.
We are MSThralls here. No Java. Sounds like a good notion
<- Own the solution? Defend the problem.
>I must remember to quote that elsewhere ;-)
Or invent a problem to solve with a means
Life in a ricebowl. Controlling which means
get chosen to control the means to solve a
problem is how secret societies control
the destiny of man. Ooops... now the Bilderburgers
have to eliminate me too. (Gotta quit
watching History's Mysteries while I edit...).
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h