Re: Sample Question

At 01:30 PM 1/30/97 -0600, Len Bullard wrote:
>W. Eliot Kimber wrote:
>> 
>> At 10:36 AM 1/30/97 -0600, Len Bullard wrote:
>> >Will the following example be koscher XML?
>> >
>> ><HTML>
>> ><HEAD>
>> ><TITLE>Hello World</TITLE>
>> >.
>> >.
>> ><P>Your IP address is <SERVER>write(request.ip)</SERVER>
>> ><SERVER>write("<p>Last time your were " + client.oldname + ".")</SERVER>
>> 
>> No (because <p> tag is not closed).  But this would be:
>> 
>> <P>Your IP address is <SERVER>write(request.ip)</SERVER>
>> <SERVER>write(
>> <![CDATA["<p>Last time your were " + client.oldname + "."]])</SERVER>

What about this alternative:

<P>Your IP address is <SERVER>write(request.ip)</SERVER>
<SERVER>write("&lt;p>Last time your were " + client.oldname + ".")</SERVER>

An addition of 3 characters.  The escaping could easily be provided by the
sort of 10-line Perl script XML was specifically designed to enable the
writing of, assuming that script understood the semantics of the Server
element.

We can't change the fact that many things in HTML trample wildly all over
basic principles of SGML because the designers of these hacks didn't make
the distinction between the application (HTML) and the syntax used to
represent the data of that application (SGML), and thus conflated lexical
parsing with semantic recognition way worse than it is in SGML itself.
It's like saying that this should be valid Perl:

sub do_something {
   &start_printing();
   sub some_stuff {
       # this isn't code to be executed, it's code to be printed
       $a = $b + $c;
   }
   &stop_printing();
}

Because we understand that the lexical parse occurs *before* the semantic
parse.  But not in HTML processing.  I don't get it.  
  
The risk taken was investing in a delivery language designed too quickly by
people who's only apparent goal was the shortest path to the quickest
solution.  If the world was fair, I could say they deserve what they get,
which is a pile of hacked crap, but the world's not fair, so we do have to
be sensitive to these people.  But that doesn't mean we have to accomodate
every half-baked hack that comes out of Mountain View or Redmond or
Cambridge or wherever.

It means we have to carefully weigh the relative costs against XML's stated
design goals and target audience, with as much thought as possible to
future.  XML, like SGML, has a responsibility to the long-term interests of
its users. Propogating bad hacks is usually not in those interests, even if
it costs short-term pain.  Hard cases make bad law and entrenched hacks
make bad standards.

XML is lower-cost SGML.  That doesn't mean it's necessarily pain-free SGML.
 Doing the right thing often hurts ("Come to the Dark Side....it is
your...Destiny").

Cheers,

E.

Received on Thursday, 30 January 1997 17:32:10 UTC