[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MS Word as XML editor?
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: John Turnbull <firstname.lastname@example.org>,"'email@example.com'" <firstname.lastname@example.org>
- Date: Thu, 07 Jun 2001 16:13:49 -0500
Title: RE: MS Word as XML editor?
Precisely and well said. I and others have said that to
surprise, we find users who eventually turn to editing XML with
editors. Of course, what that hides is that they are
performing a text update operation and for that, little
is needed once they are comfortable with the markup.
other hand, as more operations are posted, that quits
effective. The well-designed schema or DTD has been
crafted with an understanding of the "acts" as you say in
it will be involved. The most difficult part of that in
experience is getting all of the users to understand
least tolerate a design that either fits to these acts
be transformed appropriately.
schema context sensitivity is only the first part of that
where most editors quit being adaptible. I find that
such products are limited by the vision afforded by
experience of their designers. It is like the Adobe
products that promise a new vision of the web but
one visits the site, their own vision has not gotten
further than the VRMLers did by 1997. So even if the
is faster, nothing more is possible. It is
surprising then that the best XML editors are coming
the SGML companies that have already been
through enough RFPs and initiatives to have grasped
larger vision that emerged in that period and is only
now affordable given the innovations of the web
engines for transport and content identification.
sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: John Turnbull
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
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