OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Open Source XML Editor

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

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

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

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

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

<- A LOT of software companies are still grinding out
<- hypertext that is mundane and production-intensive because
<- the tech writer leads and their managers refuse to use
<- database-driven systems.  So customers request paper
<- copies for various good reasons and these companies
<- refuse to give them source that would enable this
<- and claim that everyone knows that digital is the
<- only way to go.   They defend that ferociously
<- as a cost savings for the customer all the while
<- really defending their own arcane methods.  Fact
<- is, it's a con.  A decent hypertext format with
<- transforms lets any device get the information
<- as needed in the format needed and that includes
<- the old devices... like paper.

I've no personal experience of this, but this sounds painfully plausible.

<- Own the solution?  Defend the problem.

I must remember to quote that elsewhere ;-)