RE: MS Word as XML editor?

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

Title: RE: MS Word as XML editor?

Precisely and well said.    I and others have said that to our great

surprise, we find users who eventually turn to editing XML with

text editors.  Of course, what that hides is that they are

only performing a text update operation and for that, little

more is needed once they are comfortable with the markup.

On the other hand, as more operations are posted, that quits

being effective.   The well-designed schema or DTD has been

crafted with an understanding of the "acts" as you say in

which it will be involved.   The most difficult part of that in

my experience is getting all of the users to understand

or at least tolerate a design that either fits to these acts

or can be transformed appropriately.

 

DTD or schema context sensitivity is only the first part of that

yet is where most editors quit being adaptible.  I find that

many such products are limited by the vision afforded by

the experience of their designers.  It is like the Adobe

3D products that promise a new vision of the web but

when one visits the site, their own vision has not gotten

further than the VRMLers did by 1997.  So even if the

code is faster, nothing more is possible.    It is not

surprising then that the best XML editors are coming

out of the SGML companies that have already been

through enough RFPs and initiatives to have grasped

the larger vision that emerged in that period and is only

really now affordable given the innovations of the web

engines for transport and content identification.

 

Say FRED?

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

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

From: John Turnbull [mailto:jturnbull@softquad.com]

From a user's point of view, Word produces different kinds of documents: my project reports are different from my RFPs provided I view them in Word. But from  any other point of view -- a developer's, a machine's -- the differences are meaningless. Both the project report and the RFP are pretty much the same.

To do any significant processing on those two different kinds of documents, there would have to be a detailed prior agreement between the user and the developer. So the problem is not simply to re-express in XML whatever the user happened to do, it's to hold the user to this agreement -- in the gentlest possible way. In other words, we can wrap strings in tags and put "xml" on the file extension, but unless we agree about the meaning of the tags names (and other details), we have accomplished very little. The production of useful, valid XML that adheres to a prior agreement in a practical editing interface presents such a difficult set of problems that only a tiny handful of companies has even considered it. Two or three have succeeded.

But that's just the beginning. The more interesting problem is how you make a project report *act* differently from an RFP during its creation, or make a legal contract act differently for the user, than does a set of meeting notes. When you succeed at that, you are no longer just constraining your user, you are simplifying the authoring task while you assure yourself of input that your software can safely process.

The distinctions among editors that produce valid XML have very little to do with the production of a valid document, but a great deal to do with the degree to which they are open to customization and integration into larger XML systems. When these systems evolve, the customizations and integrations have to evolve with them. Good XML "editors" are actually developer tools that allow the creation of good XML editing interfaces -- for any kind of document. Most XML editors fail at both levels.