1 / 44

20 years of abstract markup Any progress?

20 years of abstract markup Any progress?. Brian Reid Compaq Computer Corp. Palo Alto, California USA. http://reid.org/~brian/markup98.html. 20 years of abstract markup Any progress?. descriptive markup. generic markup. nonprocedural markup. abstract markup.

mhan
Download Presentation

20 years of abstract markup Any progress?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 20 years of abstract markupAny progress? Brian ReidCompaq Computer Corp. Palo Alto, California USA

  2. http://reid.org/~brian/markup98.html 20 years of abstract markupAny progress? descriptive markup generic markup nonprocedural markup abstract markup Brian ReidCompaq Computer Corp. Palo Alto, California USA

  3. Outline • What I thought about markup in 1981 • What I think about markup in 1998 • Why I am no longer in the markup profession Markup Technologies 98

  4. Given at EPFL Conference on Document Preparation Systems, Lausanne, Switzerland; 21 February 1981

  5. EPFL Lausanne

  6. EPFL Lausanne

  7. EPFL Lausanne

  8. EPFL Lausanne

  9. EPFL Lausanne

  10. EPFL Lausanne

  11. EPFL Lausanne

  12. EPFL Lausanne

  13. EPFL Lausanne

  14. EPFL Lausanne

  15. EPFL Lausanne

  16. EPFL Lausanne

  17. EPFL Lausanne

  18. EPFL Lausanne

  19. EPFL Lausanne

  20. EPFL Lausanne

  21. EPFL Lausanne

  22. EPFL Lausanne

  23. EPFL Lausanne

  24. EPFL Lausanne

  25. EPFL Lausanne

  26. EPFL Lausanne

  27. EPFL Lausanne

  28. EPFL Lausanne

  29. EPFL Lausanne

  30. EPFL Lausanne

  31. EPFL Lausanne

  32. EPFL Lausanne

  33. EPFL Lausanne

  34. Observations • Most people won’t use abstract markup even if you threaten them • It is hard to find agreement about structure and abstraction • Selection is easier than synthesis, but the universe is not finite Markup Technologies 98

  35. Thinking about structure Markup Technologies 98

  36. Thinking about structure Markup Technologies 98

  37. Not just markup • Floss every day • Drive the speed limit • Don’t eat junk food • Change oil every 3000 miles • Leave 1 car length for each 10 miles per hour • Change your password often Markup Technologies 98

  38. It’s better to have… It is better to have whisky to see you through times of no money than to have money to see you through times of no whisky old Celtic saying Markup Technologies 98

  39. Skill or knowledge? • With procedural markup, skill and experimentation can make up for a lack of knowledge. • With descriptive markup, no skill will save you. You must have knowledge. • The computer industry has always favored skill over knowledge. Markup Technologies 98

  40. Need for knowledge and experience is everywhere • Must know the menu of tags to perform markup • Creating a DTD requires ability to produce abstractions, which requires broad knowledge • Knowing whether a new DTD is appropriate requires knowledge and wisdom. Markup Technologies 98

  41. Knowledge isits own reward • Our culture does not reward knowledge, it rewards results • Most observers cannot distinguish quality of good markup from bad • Any scheme based on knowledge and quality will remain at the fringe Markup Technologies 98

  42. Is there a solution? • Stop caring and keep doing it well. Knowledge is its own reward. • Automate. Computers don’t mind having knowledge. • Go do something else. There’s always a future in teaching word processing. Markup Technologies 98

  43. Conclusions • Markup has nothing to do with publishing. • It is a mathematical abstraction in the field of data/information. • It has surfaced in publishing because of the correlation between publishing and information EPFL Lausanne

  44. Conclusions, cont’d • Abstract markup will never solve the publishing problem • Attempts to force it will generate further complexity • XML should be called X.ML • Java will dominate X.ML: it admits it is procedural, rewarding cleverness EPFL Lausanne

More Related