Lists Home |
Date Index |
- From: Marcus Carr <firstname.lastname@example.org>
- To: Ketil Z Malde <email@example.com>
- Date: Wed, 30 Jun 1999 10:10:48 +1000
<DrollDisclaimer>Yes, the company that I work for sells FrameMaker+SGML, but I
have no connection with product sales. I design and implement data collection,
storage and publishing solutions.</DrollDisclaimer>
Ketil Z Malde wrote:
> Perhaps I misunderstood. What are they working with, and why is a
> WYSIWYG environment focusing on fonts and colors, better than one
> displaying the document structure?
There is always a danger that when any group of people with a similar interest
discuss that topic extensively, they start to create a perspective that looks
ridiculous to outsiders. Your sentence seems to imply that prior to SGML and XML,
there was no structure to documents. All XML does is formalise the structure, not
create it - structure in documents predates XML by many thousands of years.
Technical writers are at least one group who would be very disappointed to be told
that their documents consisted of "fonts and colors" (and of course the words).
> I maintain it is much better than pretending the structure doesn't
> exist by covering it under formatting issues.
The user doesn't pretend that it doesn't exist - they still select elements and
assign attribute values. If you would prefer to dispense with all those fonts and
colors, you could design a stylesheet that left all the text as Courier and invoke
the View-->Element Boundaries as Tags option and presto - it would be exactly the
guided syntax editor (GSE) you seem to desire.
Tables are a great example of where you should use a WYSIWYG application. Have you
marked up many CALS tables? Even the most hardened vi pilot could see the sense in
doing a complex table with extensive vertical and horizontal spanning in something
other than a GSE.
> I would say that while I agree that the world would be a better place
> if lawyers were replaced by those understanding XML, writing of
> legislation is a highly specific, complicated process, while tags are
> a really simple concept.
They are overhead. They simplify your life at the expense of complicating someone
elses. You can't pretend that away.
> Well, don't tell them then. Give them an XML format with <b>, <i> and
> <u> tags hooked up, congratulate them on being XML-aware, and receive
> a pat on the back.
The pat on the back would likely be exploratory, perhaps seeking a spot between
> No, that's not what I'm saying at all. I'm saying that pretending the
> structure is automatic and derived from formatting information is
> bogus, void and in error. If you want "good data", you need to
> educate users about structure. Yes, I know this is hard and
> unrealistic. It is still the right thing.
I'm getting the slightly uneasy feeling that you may not have spent as much time
looking at these applications as I thought you had. You do realise that these
documents accept a DTD (albeit compiled to an internal format) and that the users
are conscious that they're creating structured documents, don't you? They
understand structured documents - remember, structured documents predate XML. The
DTD has been designed to accommodate the data that they're creating. Along the way
it might seek to enforce what the authors have decided is good practice, but in
essence XML is the scaffolding - the data is the building.
Marcus Carr email: firstname.lastname@example.org
Allette Systems (Australia) www: http://www.allette.com.au
"Everything should be made as simple as possible, but not simpler."
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)