Comercial XML editor recommendations
Peter at ursus.demon.co.uk
Thu May 29 10:45:44 BST 1997
In message <199705290352.UAA08842 at shell1.aimnet.com> Michael Leventhal writes:
> Peter Murray-Rust wrote:
> I'd like to, but I am very concerned about misusing this list for commercial
> purposes, despite the invitation. I think I can mention that Grif did demo
> _two_ XML editors at SGML '97 Europe and WWW6.
I appreciate this restraint, thanks - but would like to suggest that we can
relax it a bit *at this stage in XML development*. My reasoning is as
follows. [BTW there is absolutely no *pressure* for any m'facturer to say
anything here in advance of public release - and no inferences should be
drawn from any apparent silences. So if there is no response - for
good commercial reasons - fine. I take it as axiomatic that all major
current SGML m'facturers are *interested* in XML, so silence carries little
Implementations tend to define de facto procedures. For example when C++ came
out it was an almighty mess. There were several different compilers, all from
different manufacturers and working to different levels and by different
mechanisms. Some used a preprocessor, some were native, some had templates
and all on a varying timescale. You very soon got not only m'facturer
lockin, but version lockin :-(
The XML-spec is not yet frozen, but people are (rightly IMO) creating
tools in advance of the final spec. Let's say those tools suddenly
emerged on July 2 (spec is announced July 1. right?) and they take
fundamentally different approaches to the language, that *may* have some
bearing on language revisions. We are concerned that XML does not have
multiple conformance levels, and a comparison of editor/parser features may
help to approach that problem.
Many *document* developers may be wishing to create trial XML documents
or prototype legacy conversion. It would be reasonable for them to
ask where they could find a (prototype) editor to start with. They might
then discover that there were significant problems/advantages in XML.
[Some of these problems may also be dealt with if people compile XML
> I also think I can pursue Peter's point about there being two types
> of editors, A and B above, from a technological/philosphical/cultural
> perspective. Grif also has an A and B which are not exactly what Peter
> describes but sort of close. The origin was not intended to delineate a
> philosophical distinction although the currents of history may have in fact
> made it so.
My motivation here is that I see editing as one of the key steps to getting
XML universally accepted. Yes, the current text-oriented SGML tools will
be modified/rewritten to give XML editors, but they won't address the
applications that no-one has thought of. What does a CML editor want?
> Grif's XML editor A is a knock-off from its traditional SGML with
> "WYSIWYG to the max" product. It requires a DTD, enforces structure,
> and controls the presentation through a high-end style sheet mechanism.
> XML editor B is a knock-off of Grif's HTML editor, Symposia, and does
> not enforce structure, allows you to add tags at will, is CSS-based
> and does the usual HTML-related stuff like allow you to create
> (XML) links and image maps, add math, etc.
This is very exciting news. I would be interested to know more.
> I initially found the idea of having two XML editors to be possibly
> schizophrenic so I am intrigued by Peter being already in possession of
> a two editor world-view, essentially the SGML and the HTML
> approaches, DTD-required vs well-formed. I guess I always assumed
> that you'd combine the two, change modes at the flick of a switch,
> but somehow encourage more rather than less structure by always
> having the capability of showing the user his or her structural
> failings. Of course, the code bases have, by now, divurged greatly
> though companies like Grif certainly leveraged their SGML experience
> in entering the HTML fray. But I thought the perspectives were coalescing.
> Is this two editor approach a transitional stage on the way to a more
> glorious evolutionary stage or have we, in fact, distinguished different
> types of tasks to which different types of tools have been precisely tailored
> to exact nature of the task?
What I want for an editor for the chemical community is, I think,
generalisable to may other applications.
(a) no discipline-specific tools, but good hooks to link them in
(b) full support for XML-LINK
(c) tree-based editing
(d) attribute editing , controlled by DTD
(e) import of legacy data and conversion on the fly by user-written add-ons
(f) support for whatever solutions XML comes up with for XML-TYPE, XML-LINK
(g) WYSIWYG HTML editing with XML-LINKing to imported subdocuments.
(h) Cunning chemical editing that I think of and develop.
*I* can do the *chemical* bit. I'd prefer to do it once and not one for A's
tool, one for B's tool, etc. My current preference for several reasons
would be Java beans - e.g. there will be a HTML bean, Word bean, Molecule
I have always felt that posters to comp.text.sgml have been very responsible
in the use of commercial postings. I think that a listing of current
capabilities of editors would be valuable to readers of this list.
However if people don't general share this view, please post - either to the
list or me personally - and I will then suggest revised etiquette.
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)
More information about the Xml-dev