Re: Recent ERB votes

Paul Prescod wrote:

> I am not convinced. You can't just wire SP into a browser front-end and get
> "SGML on the Web". It requires too much meta-data. SGML wasn't designed for
> this environment, and it doesn't "fit". To get the performance we need, we
> have to have a mechanism for signalling empty elements that does not involve
> downloading the whole DTD.

So you will *wire* in a stylesheet and require Scheme parsing, and you 
will require the author base to become proficient programmers, and 
you will require the SGML industry to rewrite its applications and 
translate all of its large (Very Large, Paul) information so two 
browsers won't have too?

Excuse me, Paul; that's dumb on the face of it.  As for SP, no comment.
We aren't redesigning SGML here.  My thought was that we would try 
to see where we could do without features to get a better fit.  But 
it goes both ways.  I have no problem with <e/>.  That is trivial 
to fix.  You may find your government has more problems with it 
than we do.  

> In that case, we don't have to have a heated discussion of the issue,
> because one way or another, the show goes on.

Unfortunately, we must.  My feeling is that without some adjustment, 
credible members of the SGML community and ISO are being used to 
lend credibility to the incredible.  

> >I see
> >the same arguments being presented to defend HTML compatibility
> >that are used to defend SGML incompatibility.  I see nonsense, and
> >pure and simple also-rans taking advantage of this situation.
> 
> I don't know what you mean by this.

Every time a requirement to satisfy the requirements of the
international 
standards requires a bit of work, arguments appear that we don't need
this.  Every time we require an adjustment to HTML, we see silly 
kludges.  That is nonsense.  Again, I don't care about </e>.  But 
grandfathering tags from HTML, that is ludicrous.  It's bad design for 
the sake of politics and the personal and economic advantages of those 
empowered to vote.   You are willing to wreck the relationships of 
W3C to WG8, split the SGML community, dilute both markets, whatever, 
to keep your privileges and browser.  See Scottish history and 
a fellow named Wallace:  "a parcel o' rogues in a nation".

So, yes, I think this must be discussed now before this goes one 
step further.  This is the easy part of this design.  The next 
part is a lot harder.  Decide now so some of us can decide 
where we can best focus our own efforts.
 

> As far as I know, nobody is proposing any version of XML which is not SGML.
> What is being proposed is encoding of new semantics within SGML compatible
> syntax, which will require a post process to transform from the SGML
> produced by most SGML tools to the SGML subset that is XML. It is still SGML.

See Charles' posts to Eve.  He says no.  He is the most credible
authority 
in this working group.
 
> So even if XML was an SGML-incompatible generic markup language, W3C
> would be using _our_ loose terminology to describe their new technology. But
> nobody is proposing that.

If it is a W3C competitor to ISO, it is a bald faced failure.


> I dunno. I don't care. When it is in my best interest I will champion the
> causes of big, stupid, nasty corporations. As you'll see in my tagline, I
> like to encourage people to use Esso/Exxon or Texaco, because they are the
> lesser of x evils. Microsoft and Netscape are the cable companies. We have
> the content. We must conform to their content guidelines (no frontal nudity
> or undistinguished empty elements!) if we want wide viewership. If we don't
> want wide viewership, then we can just use our VCR (Panorama).

Your TV must be wildly different from mine.  None of those content 
guidelines are obeyed.  They are given lip service.  Pardon, but that 
I can get on any street corner.  I champion the cause of corporations 
when it makes good sense, technically or economically.  Otherwise, 
when they are wrong, they are wrong.  MS was not able to move the 
VRML community precisely because the self-interested yielded to the 
greater good, and because they valued the ownership of their own work.
The tactics of the Mafia don't work well when the store owners resist.

> If you believe that full-blown SGML on the Web is feasible on today's
> network, we can continue to work towards that goal. Standards compliance is
> important, and I believe in it. But generic markup is important too -- more
> important, in my hierarchy. Otherwise why not standardize troff back in 1986?

They tried.  But full-blown SGML is not what we are discussing. 
Otherwise, 
this work would not be needed.  I only object to grandfathering HTML to 
the exclusion of any other considerations.  I am reasonably pleased 
with the other decisions.  Truth is, in XML 1.0 I would be quite a bit 
more restrictive, but I yield to those who insist that IGNORE and
INCLUDE, 
parameter entities, etc. are of "great value".  In most cases, I am 
confident these individuals are protecting their own interests, but 
I defer on issues I can ignore.

> I want to make the generic markup Mass available to the laity. If that means
> translating it out of Latin, and losing a certain connection to the past,
> then so be it. It looks like the "translation" is going to be relatively
> trivial (and, perhaps, non existant).

A work for your deity might deserve more respect.  That is a personal 
decision.  But if you alter the word of God and consider that trivial, 
one might wonder about the depth of your worship.  Convenience in 
some things is mortal, not venal.  

Yet this is technology and legal, validatible agreements; contract law,
not holy canons.

> I think it is. Nobody wants to introduce incompatibility with existing tools
> as a joke. My understanding is that fast, easy recognition of empty elements
> is the ONLY reason for this new empty-element syntax. What do you think _is_
> the issue?

Grandfathering HTML vs political suicide.  Not my term.  Part of the 
explanation for the ERB vote.


> Yes. SoftQuad tried. We tried at the University of Waterloo. In the end, we
> decided to ship ESIS over the web. Panorama also requires a normalization
> process, and STILL requires the DTD. You posit that a satisfactory product
> can be built using today's network and today's processors without changing
> the output of SGML tools. I do not believe it. I could be wrong. Even if it
> is possible, that wouldn't make generic markup browsers ubiquitous, which is
> my personal goal in this endeavour.

Try shipping markup.  Try NOT doing full blown SGML.  Try shipping
groves.
Try a lot of things, but don't claim because you couldn't do it, others 
can't.  I use a very simple form of SGML everyday.  It works nicely.
I did not say we would not change the output of SGML tools.  We just 
don't use a lot of features.

> If NS and MS reject XML and ISO releases a competitor, then we have gambled
> and lost, but lost only our time (which will SURELY be recycled into the ISO
> work anyhow).

That isn't gambling; a gambler bets odds.  That is a rejected design.
It is a failure to implement.
 
> On the other hand, if NS and MS embrace XML, then we have transformed the
> world's largest information system into a generic markup based system.

No we haven't.  They have.  I doubt they will unless economics compels 
it.   NS shows absolutely no interest, and MS won't even do us the 
courtesy of participation other than voting their interests.
 
> "A Generic Markup Browser on Every Desktop"

Only if we build one.  Don't expect it otherwise.
 
> I consider this a gamble with a million dollar prize and a 50/50 chance of
> winning. And I suspect that most members of the SGML community (which, IMO,
> is represented on the ERB) will be happy to take money from our new citizens
> and do a good deed at the same time.

I don't gamble.  That is for suckers.  As for who the ERB represents,
they 
represent themselves and possibly their companies.  So do I.  They vote 
and that becomes the spec.  I don't.  Them's the breaks, but hey, 
no one has to implement the thing if there is another more compelling 
competitor.  As it is said, "standards are nice; so many to choose
from".

No grandfathering of tags.  That is an application problem.

len bullard

Received on Monday, 11 November 1996 09:18:49 UTC