[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] re: abstraction
On 16 Nov 1999 rev-bob@g... 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|