[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open Source XML Editor
- From: Danny Ayers <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 13 Feb 2001 23:35:35 +0600
<- 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 ;-)