Re: Advice on XML editor development

francis (francis@redrice.com)
Tue, 28 Apr 1998 10:14:03 +0100

Peter Murray-Rust wrote:
>
> At 21:30 27/04/98 +0800, James K. Tauber wrote:
> >
> >What I am envisaging is a generic editor that given an editing sheet for
> >MathML would become an equation editor or given an editing sheet CML would
> >enable editing of molecular structure diagrams. Of course, such editing
> >sheets would include code but that code would presumable have a lot of
> >overlap with the code attached to XSL stylesheets for display. I would
> >imagine Java Classes, for example with both display and editing interfaces
> >for this purpose.
>
> I have thought about this a lot and have been working on about the third
> version for CML support. Say we are working at a node-centered level - e.g.
> the DOM/JUMBO or whatever knows about <MOL>...</MOL> but there is no point
> in either a tree- or eventstream display or editing of the children. We
> click on <MOL> and might expect the following types of functionality:
> - display() // to anywhere , probably a new JFrame
> - getDisplayComponent(boolean editable) // returns a JComponent which
> // can be embedded in a TabbedPane, Table, etc.
> - highlight(String foreignAddress); highlights a subcomponent of the
> object (e.g. an atom in a molecule)
> - drawToGraphics(Graphics g, Scaler s);
> // draw onto an exiting graphics so that many objects can be rendered.
> Scaler is a GKS-like scaling (I expect Java2D will supersede that)
>
> This could be very general - it would allow a molecule and a maths eqn to
> be draw to the same surface, either to be edited, parts of them to be
> highlighted, etc.
> I am reasonably confident this will work - if others are interested in
> following this discussion I'd be delighted.
>

Yes, I'm interested in following this discussion. I'm wrapping web and
client-server transactions from an existing toolset in XML, and want to
build a tool for editing interfaces which map XML requests to XML
sources, which may well have different DTDs.

This isn't precisely what you're talking about, I know, but one point of
contact, at least, is the component-like, three-phase structure: if I
want to re-use these interfaces then I need to be able to (1) build the
interface, which involves using the DTD of the source (input) XML; (2)
re-use the interface, which involves publishing the target (output) XML
DTD so that it can be used as another component's input; and (3)
actually execute the interface, reading stuff in the input XML format
and generating stuff in the output format.

I don't have an SGML background so my head's been hurting a bit as I try
to evaluate the options: xml-link/xml-pointer vs namepsaces vs
architectures vs XSL vs XML-Data vs ... even the range of different ways
of referring to XML elements is slightly numbing!

I need to start coding the editor soon - having read David's
architectures for XML proposal I'd like to look into that, because I
suspect it may allow me to do the whole thing declaratively (of course
this may simply show how little I understand it), otherwise I suspect
I'll be building a micro-meta DTD (for publishing what input and output
formats an interface supports) so that I can start building the editor
while encapsulating, and delaying till I understand it better, the
actual mapping design and technology.

Oh, I'm also London based. If anyone's around who doesn't want to go as
far as Paris to be able to talk XML without people's eyes rolling, I'd
be on for a drink some time...

Cheers -

Francis.