[Prev][Next][Index][Thread]

Re: XML vrs SGML tools [was Re: Capitalizing on HTML (was ...)]]]



> XML on its own does not solve the browser problem.  The browser
> writers are still faced with the problem of style sheets.  The reason
> there are so many cheap HTML browsers is because it is _very_ easy to
> figure out how to display HTML (well, for the most part).  DSSSL may
> solve the problem, but it solves it in a rather difficult to
> understand and implement way.  XML will be an easy sell to browser
> writers if it comes packaged with a useful but simple style-sheet
> mechanism.  DSSSL might work, if someone would write a good book about
> it, or at least about DSSSL online.  Maybe Cascading Style Sheets
> (CSS) is an easy (quick and dirty) answer; I have not had a chance to
> look into it properly.  There was a great deal of discussion about why
> CSS is too simplistic a month back on comp.text.sgml, but it may be
> "good-enough" for a first run.  Every one here seems to want XML tools
> today, but we don't even have a DSSSL capable browser now, how many
> months after the standard's publication?

Hey, DSSSL isn't trivial--neither is the problem of "presentation."
There are three DSSSL engines in the works.  James Clark's engine 
is already in alpha testing. 

> I do not mean to cut down DSSSL.  DSSSL looks to me to be a great
> possiblity, for the future.  A XML/DSSSL browser will not be able to
> compete with a HTML browser in today's market though.  It will look too
> slow.  It will definitely have a market, but it will lack a real
> mass-market appeal.  (But boy would I kill for a good, extensible
> DSSSL browser to play with... with some work on on-line display
> extensions to the standard, you could use SGML/DSSSL to do everything that
> HTML, CSS, Java, Javascript, etc are _trying_ to do now.  Now that
> would be fun.)

Too slow?  I don't really think that is necessarily true.  We are seeing
very good response times on DSSSL formatting without *any* optimization
or use of a JIT compiler.  (Our DSSSL engine is written in Java).

> XML is one important part of the picture, and although DSSSL is one
> way to help fill in the whole picture, I don't see it as being an
> immediate answer.  No, I don't have any better ideas, and I would love
> to be proved wrong. (This is one of those rare cases where I _want_ to
> be wrong.)

The only way to ensure that XML and DSSSL will be a solution is to require
some level of DSSSL compliance.  The question is (James, correct me on
this one) is there a minimal set of features that could be defined that
would allow a DSSSL engine to be "easy" to implement but still be 
compliant with the DSSSL standard?  Is this DSSSL-online?

DSSSL is a "today" solution if we want to make it so.

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608


References: