[Top][All Lists]

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

Re: HTML 4/XML+CSS2 front-end

From: Valeriy E. Ushakov
Subject: Re: HTML 4/XML+CSS2 front-end
Date: Tue, 5 Jan 1999 22:31:33 +0300

On Mon, Jan 04, 1999 at 11:11:01AM -0000, MatЛj Cepl wrote:

> > As you correctly point out, it's the same as many things on the free
> > software world.  You could invest in the open source product to make
> > it up to your task or you could invest in the commercial product that
> > is up to your task.  In most cases you have to invest and you just
> > decide which product, free or commercial, to invest into (with all due
> > respect to RMS, I don't share his hatred to commercial software, but
> > that's a quite different topic).
>       [MCepl]  Well, RMS position on commercial software is not so
> rigid as you are suggesting -- I am not able to get on
> http://www.gnu.org, but there is some article about possibility of
> selling free software).

Selling *support* to free software.  Actually, GPL is based on the
*axiom* that commercial software is a BAD THING and this world view is
the very reason for GPL to exist.  I'm willing to discuss this in
private email, but this is an off-topic for the list.

>       [MCepl]  I can agreee, that vendors are reluctant to add new
> features, but I cannot see why they would not want to make bugifxes. If
> anybody makes his documents non-compliant with manual to overcome bugs,
> thus making his own bugs, let him suffer.

One possible scenario is when vendor underspecifies something and
suddenly there's a big customer that read the spec one way while
vendor would like to change (specify) it another way.

> Moreover, to your comment, that I can make changes.  Well, I cannot,
> because I am a lawyer and I have no time to learn programming.

With open-source you can ask someone (or pay someone) to do this for
you.  You pay to a vendor or pay (or not;) to a volunteer programmer
that will do this.  Vendor might have other priorities, as well as a
volunteer programmer do.  There're both positive and negative moments
in both situations.

> > > You are saying, that HTML4 does not have a future. 
> > 
> > Huh?  I haven't said this.
> > 
> > I don't think this route makes sense.  If you want to target multiple
> > formats your best bet (in the long term) is SGML+DSSSL/XML+XSL.
>       [MCepl]  Well, you said this. Which seems to me pretty close.

Saying that some tool is not applicable in some situation and saying
it's useless are two quite different things.

> > I bet that 95% of the web will not pass through an SGML
> > parser.
> > 
>       [MCepl]  Well, my documents are 100% text and 100% valid HTML
> (my biggest project was periodically tested until it fitted in HTML form
> -- I am not able to upload and I do not know about any email-aware HTML
> validator) according to validator.w3.org (or was it at
> www.htmlhelp.org?).

I use SP (the SGML parser that Jade uses) to validate my HTML.

> > If you stick to the rigid valid HTML, that using XML/XSL is just one
> > little step away (SGML/DSSSL being the next step), but making this
> > step gives one (in theory, at least) significant benefits, as you step
> > on the firm ground of *standard*.
> > 
>       [MCepl]  Well, HTML4/CSS2 are standards as well, aren't they?

In theory yes.  In practice Netscape and Microsoft bent it at their
will.  And even *standard* HTML is too weak for both nontrivial
structural markup and, with style-sheets - nontrivial presentation
markup.  The only real advantage of HTML is there are lots of code
that can understand it.  There're lots of code to deal with HTML
because it's simple.  But since it's simple - it's like that Jack of
many trades that is a master of none.

>       [MCepl]  But SGMLTools and DebianTools DTDs are so primitive,
> that not usable for me.

Rethorical question: is HTML really any better?  It has tables, but
that's about the only relevant advantage for the type of usage we are
discussing that I could think of off the top of my head.

I don't know much about XSL, but I've read DSSSL standard a few times
from cover to cover and it's *very* good.  SGML/DSSSL XML/XSL are
complex, but that's because they're designed to solve complex tasks.
And that is when vendors (be they open-source or commercial) comes
into play by providing a tool(s) to manage this complexity.  And we're
back to the problem of making investments.

PS: Please don't take it as grumpiness.  I, myself, *do* want a tool
    (so that's not very urgent yet) that would allow me to target
    multiple distribution formats.  But currently I have neither money
    nor time to invest.  The few spare time slices I have I invest in
    Lout, because I value its programmability, and (among other
    things) I hope that when I will have a bigger time slice, I will
    be able to build upon the expertise.

SY, Uwe
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]