Re: Recent ERB votes

At 08:19 AM 11/11/96 -0600, Len Bullard wrote:
>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?

We are talking about web delivery of documents, right? On the current
network there is _LOADS_ of time to do the necessary conversions as a
server-side CGI process. Eons. DynaWeb does SGML-transforms in real-time and
delivers the HTML pages almost as quickly as if they were static HTML.

So I certainly do NOT propose that you do some mass, batch conversion of
gigabytes of data to XML. On the other hand, later in your message you seem
to say that you would NOT mind doing so if it were necessary.

>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.       
    ^^^-- surely it can only be fixed by modifying your existing documents!


That is the issue I thought you were concerned about. It is, after all, the
major issue that requires a transform from the output of SGML tools to XML.
This HTML hackery that is being discussed is not incompatible with SGML in
any way, shape or form...it is just a "special case", which good designers
tend to try to avoid. In a sense, it is a case where a small subset of XML
documents are "incompatible" (or, lets just say "different") from the majority.

I think that there is a better way, and I've proposed it, but I will still
support XML if it has the HTML-hack in it.

>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".

Methinks you overstate the case. W8G is not going to smash down W3Cs door
because W3C came up with another imperfect standard in the name of
backwards-compatibility. Considering the hackery that Charles has proposed
in this venture, he understands political realities. Just as he is proposing
a "special notation" for XML documents that makes their RE/RS handling "real
SGML" (in the letter of the law, if not its spirit), the ERB is propsing a
"special subset" of XML which is "real SGML" (in every sense), but is only
within the "letter of the law" of the SGML subset known as XML.

SGML has LOTS of hackery in it designed to support tools and standards that
are now mere memories. It seems unfair to hold XML to a higher standard. I
doubt WG8 would do so.

>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.

Well, we are almost finished part 1, syntax. Part 2 (linking) has only one
HTML compatibility concern: URLs must be usable as links, without any
special prefix. Part 3 (DSSSL-O) has no backwards compatibility concerns
because we have already decided to use DSSSL-O and not CSS. 

So the issues on the table are probably the last time that XML's HTML
heritage should be a concern.

>> 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.

Charles pointed out that there is only ONE small feature of XML that is SGML
incompatible: overlapping enumerated attribute values. He says "it is
parsing which determines conformance." Therefore the author-side issues that
we are discussing (empty elements etc.) are not issues of conformance or
non-conformance.
 
>Your TV must be wildly different from mine.  None of those content 
>guidelines are obeyed.  

Not at all. Have you ever seen an advertisment encouraging people _NOT_ to
buy products and consume ever greater quantities of stuff? There is a group
who has put up the "right" amount of money to broadcast such an advertisment
but cannot get it on the air on the networks. The networks control the
airwaves. Those who want to advertise (or show) must play by their rules.

>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 haven't yet seen how this is to "the exclusion of other considerations."
The only consideration I see being trampelled is elegance and specification
simplicity. I've proposed a solution that I consider more elegant and more
simple, but I could certainly live with the hack. As I understand it, the
hack doesn't trample the name-space of non-HTML documents and doesn't
require changes to other XML documents. As far as I can understand, it is a
side-effect-free special case. So how does it make your life harder?

>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.

And why can't you ignore the <HTML> ...<BR>...</HTML> special case?

>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.  

Translation is not generally considered "alteration". Do you read your Book
Of Worship in whatever language it was written in?

>That isn't gambling; a gambler bets odds.  That is a rejected design.
>It is a failure to implement.

We are gambling that they will not "fail 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.

Neither Microsoft nor Netscape participated in the public discussions of
CSS, either. But one has implemented and the other has promised to. XML _is_
in Microsoft's economic interest. They use SGML in-house. They are trying to
standardize their hypertext delivery. HTML is not flexible enough. They are
looking for ways to "out-standardize" Netscape. They have already
implemented style sheet support and a basic SGML parser. They have made most
of the required investment for XML 1.0 (using HTML linking and CSS) ALREADY.
Designing an "SGML for the Web" without expecting MS and NS to implement
would be like designing SGML 2.0 and not expecting SoftQuad, ArborText, and
Extoerica to support it.

XML is also in Netscape's economic interest, but I don't expect them to be
smart enough to recognize that. They don't understand documents, having
delivered so few of them.
 
>I don't gamble.  

Standardization is always a gamble. You gear your product towards your
perceived user base. You put your product out, and hope that somebody
likes/implements it. 

 Paul Prescod
---
Boycott Shell Oil worldwide!  http://www.web.apc.org/embargo/shell.htm    

"Shell is here on trial and it is as well that it is represented by counsel
said to be holding a watching brief."..."The ecological war that the Company
has waged in the Delta will be called to question sooner than later." -Ken
Saro-Wiwa to the tribunal that later executed him.
http://www.goldmanprize.org/goldman/ken.html

Received on Monday, 11 November 1996 10:33:16 UTC