RE: HTML And/Or PDF?

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 12:13 PM 5/20/99 -0700, Snavely, Deborah wrote:
>Dan said:
>> Re: HTML  And/Or   PDF?
><snip>
>In 1985 the same could have been said about desktop publishing. We still see
>"ransom notes" from every novice. The Web has made the same thing even more
>ubiquitous online. 
================================================
Defin what you mean by "ransom notes"
=========================================
>----------------------Snip
>With XML (and my recent researches into the subject), I fully expect that
>we're going to see some pretty decent exploitation on professional
>sites...and lots of really dreadful uses. What's the equivalent of a "ransom
>note" for a database structure?!? 
>
>XML lets (demands) that users design (or use template) database structures
>for their data, documents, images, or whatever's being displayed thereby.
>And so far, I've seen no evidence that it's going to take any less of an
>effort to implement in any large fashion than SGML, except that you can
>bring it up in chunks. 
=========================================================
XML doesn't demand/require database structures for their data.
It's just that XML (like SGML) makes it possible to parse a document into
its constituent atoms (i.e., elements), and store them in a database. But,
XML was made simpler in some ways than SGML for the explicit purpose of
making it more machine-readable. As far as implementation goes, anyone who's
already set up for SGML can easily accommodate XML, and translate documents
back and forth between SGML, XML and HTML, as well as in and out of a database.
===============================================================
>Theoretically, it looks fascinating and has a huge potential. 
>Practically, the path from here to there is completely fogged in!
===============================================================
Far less foggy than existing methods of moving  conventionally prepared docs
in and out of a database, or converting them from one DTP format to another,
or moving them between different platforms, or reliably converting them
to/from HTML, or translating them into different languages. These are
problems that will continue to plague the publishing and tech writing
industries until some universal format (such as XML) is used for information
exchange between people, software applications, databases, and platforms.
==================================================================
>Professionally, I expect the XML wave will be delayed by the bean-counters
>because either 
>(a) they'll support the required front-end design and implementation costs
>and that'll add a year (average) to implementation schedules, or 
>(b) they won't support the front-end costs, so that web-gurus and
>e-publishers will implement it poorly and by the method of trying and
>failing repeatedly, which in turn will delay the successful implementations
>by a year or more.
================================================================
Don't bet on it. Bean Counters are focused on Return on Investment, and the
ROI for converting to XML should be phenomenal.
=======================================================================
>Personally, I'm not looking forward to it; look what frames and framesets
>have done to the average web-surfer's experience of HTML. Ever tried to
>print the information you wanted and found a neatly printed navigation bar
>after you closed your browser window without bookmarking a stray site? My
>imagination still boggles at what an equivalent scenario in XML looks like!
==========================================================
The problem is the haphazard way those "features" were added to HTML. XML
stops all that nonsense.
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **