I think many people have been overlooking that what HTML really provides
is a structure for the presentation of information and the links between
that information and other sources.
The work that Dave Raggett, et. al. have been doing on version 3.0 is
along the lines that we need to proceed, but we never are going to be
able to satisfy all of the people all of the time.
To overcome this problem, we have implemented a somewhat cleaner
Common-Client-Interface-type system that builds on the EMBED element
that Dave Raggett introduced in HTML+.
In our system, the HTML:
<EMBED TYPE="application/acrobat" HREF="http://.../foo.pdf">
provides for the execution of a locally defined helper application that
knows how to download the HREF and then prepare an image of the output
for in-place location in an HTML document. Currently we have a small
API that handles start-up/shutdown, changing pages, losing chains (i.e.
when you can no longer go "back" or "forward" to reach the pages that
has the embedded document, the help application is informed and can free
the resources).
We are extending this protocol to include mouse and keyboard events so
the helper application can perform ISMAP-type functionality (and other
GUI interfaces) and return a modified image. In addition, we will be
modifying Mosaic for X to understand additional instructions from the
helper application, e.g. "GO TO <URL>".
I would like to discuss this option in regard to the publishing problem
as in my interactions with publishers, they are much more likely to be
able to both produce PDF as well as happier with their control over the
presentation.
This technique can be used from anything as simple as a universal image
translator helper to a complete virtual-reality environment.
dcm
--- Assistant Director mail: dcmartin@ckm.ucsf.edu UCSF Library & Ctr for Knowledge Mgt at&t: 415/476-6111 530 Parnassus Avenue, Box 0840 fax: 415/476-4653 San Francisco, California 94143 page: 415/719-4846 -------- Murray Maloney writes:Marc Andreessen writes: > > I realize the extensions in 0.9 have stirred up some attention, > but they're really not that significant relative to a lot of the > capabilities that our customers and potential customers are beating > down our doors for. We do need to figure out in relatively short > order how specs for these new features get cut-n-dried and implemented, > because the market is moving too fast to stand still and debate for > a long time, and if we don't move quickly, I guarantee each and every > person on this list that there are much bigger companies than MCom > that will be doing so, and then we're *all* irrelevant. > > I would more than welcome comments on how people on this list think > we can all move forward together quickly to address the intense > market demand for enhanced functionality -- particularly for > functionality related to advanced control over layout and > appearance, which is of urgent concern to an amazingly broad > spectrum of the potential customer base, as has been the case > for over a year and a half. > > Marc
Yes, thank you for asking this question. I wish that I had seen this before I left for Chicago rather than after getting back, but....
Someone recently said that compromise leaves one with the worst of two alternatives. I hope that is not accurate, because I am about to suggest that we all need to compromise. However, I am hoping that we can develop a language architecture that accomodates more than one formatting model.
At the conference this week, I heard a lot of polarizing statements. Some say that hard-coded style info is the way to answer the needs of WWW users, others complain that "that isn't SGML". Some of the SGML proponents suggest that external stylesheets are the way to go, while others complain about the probable speed penalties and the processing burden implied. Some publishers insist that they must have full control over presentation, while users and technology respond that local conditions and preferences must rule.
First of all, there is nothing in ISO 8879 that says that formatting information must never be encoded within any document that purports to be SGML. That is an opinion, held by a large number of people who have years of experience in publishing, information management, text processing, etc. None of us should discard this opinion out of hand, and some could stand to learn the philosophy behind it. However, it is not valid to claim that <B> is invalid SGML or that <STRONG> is somehow more valid.
There is absolutely no reason why style information cannot travel in the document and/or a style-sheet both. In cases where publishers and readers are willing to incur the penalty associated with external style sheets, why would anyone want to deprive them of their God-given right to do so. Ya, I know. Neither camp thinks that publishers or users would really want to do things the way that the other camp suggests if they really understood. Well, speaking as someone who fully appreciates the point of view being expressed on both sides -- I do understand and I want the freedom to choose.
Speaking as a publishing systems architect, as a publisher, a writer, and as a user of the WWW, I can assure you that the imperatives of both publishers and users to control format are legitimate. However, I don't think that the publishers rights take precedence over those of the user. Therefore there must be a means for publisher preferences and author preferences to be communicated with a document (within or as a style sheet), but the user must have a convenient means of overriding.
All of these things are possible. Surely it would be in all of our best interests to establish a set of design principles that would allow us to move forward while accomodating alternate points of view within our philosophy. As Marc points out, if we don't then there is a risk that an unnamed organization will simply beat us at our own game.
Murray
=========================================================================== --------------------------------------------------------------------------- Murray C. Maloney Internet: murray@sco.com Technical Publications Writer/Architect Uucp: ...uunet!sco!murray SCO Canada, Inc. My Phone: (416) 960-4031 130 Bloor Street West, 10th Floor Fax: (416) 922-2704 Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937 =========================================================================== --------------------------------------------------------------------------- Sponsor member of Davenport Group (ftp://ftp.ora.com/pub/davenport/) Member of IETF HTML Working Group (http://www.hal.com/%7Econnolly/html-spec/) ===========================================================================