Lists Home |
Date Index |
- From: "Steven Livingstone, ITS, SENM" <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 29 Jun 1999 09:26:48 +0100
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
Is such a things available yet or in the pipleline?
President, AIP Scotland.
Join Association of Internet Professionals - http://www.citix.com/aip
> -----Original Message-----
> From: Marcus Carr [SMTP:email@example.com]
> Sent: 29 June 1999 00:57
> To: Ketil Z Malde
> Cc: firstname.lastname@example.org
> 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
> 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
> with tags. What would you say to the legal expert who said that anyone
> 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
> 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
> want to say it. There is a strong correlation between what a document
> 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
> 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
> the urge to persist with that as a solution for clients (and left me with
> 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
> you create good data, but apparently begrudge others the same thing. Your
> preferred interface involves the use of raw tags; I'm maintaining that
> others may want even more help. I use MultiEdit - by your logic, I should
> running you down for looking for a guided syntax editor. It doesn't have
> 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
> 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
> oriented documents and the subject still says "XML Editors". I'm saying
> validity allows you to guide the user by restricting the available
> whereas well-formed doesn't.
> Marcus Carr email: email@example.com
> 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:firstname.lastname@example.org
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:email@example.com the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:firstname.lastname@example.org the following
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:email@example.com)
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)