XML Editors - Word 2000??

[Steven Livingstone, ITS, SENM]

I have had a look at a few editors now.

One thing that (at least the ones I have looked at so for) is common in them
is the XMl Notepad look - i.e. A line with a couple of tags and space to
insert your text.

To me it seems that this is pretty much the only way you could do this, but
feedback I have had from people not knowledgeble about XML is that they
don't consider them serious editors (although I happily work with them).

What other methods do/are XML editors using to make it very much easier for
users. I imagine some intelligent package which knew where you were in a
particular document and, working with a DTD, could provide you with a list
of possible tags which could be applied and relevent attributes (if these
apply). Of course the DTD would have to be provided as a template for the
user (as would any style sheets).

I expect (hope) that this would allow Content Providers to type as they
normally would, but give them the power of XML - of course users would have
to think as they typed (rather than the current 86,000 w.p.m that they do
now).

Is such a things available yet or in the pipleline?

steven

Steven Livingstone
President, AIP Scotland.
ceo at citix.com
http://www.citix.com

Join Association of Internet Professionals - http://www.citix.com/aip


> -----Original Message-----
> From:	Marcus Carr [SMTP:mrc at allette.com.au]
> Sent:	29 June 1999 00:57
> To:	Ketil Z Malde
> Cc:	xml-dev at ic.ac.uk
> Subject:	Re: XML Editors - Word 2000??
> 
> 
> Ketil Z Malde wrote:
> 
> > > People who are drafting XML documents such as legislation are not
> > > working with the structure,
> >
> > So they don't know about paragraphs, or references I take it?
> 
> Wow, you are grumpy. Do I really need to rephrase that sentence?
> 
> > If you insist that people bright enough to work with legislation are
> > too stupid to grok the simple context of tags, I would suggest you
> > underestimate them.  Of course they won't understand it if you do your
> > best to hide structure behind formatting.
> 
> It's not a matter of intelligence, it's a matter of focus. If you're
> paying
> a lot of money to obtain someone's expertise about the law, it's not
> practical (and may even be financially foolish) to pay them to fiddle
> around
> with tags. What would you say to the legal expert who said that anyone
> smart
> enough to understand XML tagging should be capable of writing legislation?
> Why do we assume that just because we have a need for XML data, all sorts
> of
> different professions are going to accommodate us at their own expence?
> 
> > My experiences with those tools are kind of mediocre - that could of
> > course be due to being exposed to SGML first, and the tools later.
> > The problem is that the tools focus on the wrong end of the problem -
> > how the document looks when printed on paper - instead of on what the
> > document *is*.
> 
> I'm not saying that it's the right way to go in all cases, just that I'm
> sick of having people ask if they can author in Word and me telling them
> they have to use MultiEdit or Emacs. They don't want to hear it and I
> don't
> want to say it. There is a strong correlation between what a document
> looks
> like on paper and what it is - as paper publishing is still inevitable in
> some industries, they are often nearly the same thing. It won't work
> maintaining that I've been suckered by applications - my experience in
> SGML
> predates any WYSIWYG tools by many years and even now I use MultiEdit over
> any application. Years of banging my head against the wall have cured me
> of
> the urge to persist with that as a solution for clients (and left me with
> a
> near-constant ringing in my ears...)
> 
> > Actually, forms for entering database records is much closer to what
> > I'd like for SGML input.  I like XEmacs and the psgml-based html-mode;
> > on loading a document with the .html extension, the user is prompted
> > for a title, and presented with a buffer containing a rough framework
> > of an HTML document, something like
> >
> >         <!DOCTYPE blah blah>
> >         <html>
> >           <head>
> >              <title>your title here</title>
> >           </head>
> >           <body>
> >              <h1>your title here</h1>
> >              (some empty lines)
> >           <hr>
> >           (some signature stuff, last change and a mailto: link)
> >           </body>
> >         </html>
> >
> > You don't have to be a genius to work that one out.  And this is
> > considered difficult and obscure.  If somebody is remotely familiar
> > with the editor, it's about three minutes to explain where to put what
> > information, and why, and off you go - and the built in parser
> > restricts you to the valid elements and attributes at any point in the
> > document.
> 
> Wunderbar! And you get valid HTML out the other side, you say? Have you
> tried modifying it for DocBook? Ironically, FrameMaker+SGML will allow you
> to edit your data in a visual tree-based interface, though I don't think
> much of it personally.
> 
> I find it interesting that you are looking for an application that will
> help
> you create good data, but apparently begrudge others the same thing. Your
> preferred interface involves the use of raw tags; I'm maintaining that
> some
> others may want even more help. I use MultiEdit - by your logic, I should
> be
> running you down for looking for a guided syntax editor. It doesn't have
> to
> be ugly to create correct data.
> 
> > The point is that if all you see is italics vs. normal, and you know
> > about a button which gives you italics, then that button is what
> > you're going to press.  Sure, people may mistake the meaning of tags,
> > but they are a) restricted in what context they may appear, and b)
> > labeled with (hopefully something more meaningful than typographical
> > information, and c) supplied with a helpful comment in the DTD, which
> > the editor can display.
> 
> I think you're considering users in too narrow a band - they aren't all
> bereft of any understanding about structure. They always understand what
> you're trying to achieve, they just want it to be easy for them to use. An
> application is an interface to the structure that doesn't interfere with
> the
> content. An application designer is the one that tries to ensure that both
> objectives are satisfied.
> 
> > > There aren't that many ways of assisting users with element usage,
> > > but one of the main ones might be requiring validity over
> > > well-formedness at the authoring stage and do a good job of the
> > > analysis.
> >
> > Of *course* you should require validity.  What else would be the point
> > of using SGML?  If you want formatting oriented documents with
> > no guarantee of correctness, it's not hard to find.
> 
> You're mixing up what I'm saying - well-formedness doesn't equate to
> format
> oriented documents and the subject still says "XML Editors". I'm saying
> that
> validity allows you to guide the user by restricting the available
> elements
> whereas well-formed doesn't.
> 
> 
> --
> Regards,
> 
> Marcus Carr                      email:  mrc at allette.com.au
> ___________________________________________________________________
> Allette Systems (Australia)      www:    http://www.allette.com.au
> ___________________________________________________________________
> "Everything should be made as simple as possible, but not simpler."
>        - Einstein
> 
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)