xml-dev - re: abstraction

[Eric Bohlman <ebohlman@netcom.com>]

On 16 Nov 1999 rev-bob@gotc.com wrote:

> So far, we have exactly one example class of high abstraction authoring tools on the Web 
> - the WYSIWYG HTML editor.  Is there really anyone here who will argue that the 
> development of this class was a good thing?  The questions about where this concept 
> failed are, for my purposes, largely irrelevant; I am merely pointing out that high 
> abstraction and ease of content generation is by no means a formula for a good tool.  In 
> short(er), I'm just trying to urge caution and thought before we charge gung-ho down this 
> path.

I think one of the questions about where 'WYSIWYG' HTML editors failed
*is* extremely relevant; they failed because they offered an abstraction
of something completely different from what they could create.  They
offerred pixel placement on a grid as a metaphor for the encoding of
simple editorial structures, despite the fact that there is no inherent
mapping between the two.  They didn't simply hide implementation details
from their users; they actively misled their users about what they were
implementing.

There are going to be many XML-based markup languages that are highly
specialized for very particular tasks.  They're generally what we'd think
of as data-oriented languages rather than document-oriented languages.
The programmer developing an application that uses one of those languages
is concerned with getting a set of data with a particular structure from
point A to point B.  He should *not* have to be concerned about the way
that data is encoded during transport.  Therefore, it makes sense for him
to be using an API that is designed around the data structures themselves
rather than around the way the transport is implemented.  Just as it makes
sense for him to have an API to the machine's file system that lets him
deal at the level of named streams of characters rather than at the level
of physical disk sectors.  He should *not* be dealing directly with a
general-purpose XML parser.  The person who designs the API should be
doing that.  Any complexity (and of necessity, there will be plenty of it)
in the parser should influence the parser/API interface, *not* the
API/application interface.  There should be no need to simplify the parser
for the application writer, because the API layer should be managing the
complexity internally.

The key to all this is that the application-specific API needs to be
exactly that, application-specific.  Its purpose is not to "dumb down" a
generic parser interface; its purpose is to translate the specific into
the general.  SML strikes me as an attempt to dumb down the parser
interface in hopes of avoiding this translation.  But that's on the same
level as trying to "simplify" a network card's interface in order to
eliminate the need for sockets and let the application programmer talk to
the card directly.  Few would consider the latter a reasonable goal.

An abstraction of a chainsaw in which none of the abstract objects have
the destructive power of a chainsaw is evil and dangerous.  But that's not
what we have here.


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