RE: Open Source XML Editor

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

From: Danny Ayers [mailto:danny@panlanka.net]

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

<- Own the solution?  Defend the problem.

>I must remember to quote that elsewhere ;-)

Or invent a problem to solve with a means 
you control.

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

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h