Comercial XML editor recommendations

[Peter Murray-Rust]

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
information :-)].

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.

<HINT>
[Some of these problems may also be dealt with if people compile XML
resource pages.]
</HINT>

> 
> 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
XML-STYLE, XML-MONEY,...
(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
bean, etc.

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.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

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;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)