Re: SDATA, again

>From: Tim Bray <tbray@textuality.com>
>To: w3c-sgml-wg@w3.org
>Subject: Re: SDATA, again
>Date: Mon, 09 Dec 1996 13:31:48 -0800

>Eliot is correct.  However, the ERB did take up SDATA once again, in
>response to the high level of concern in the WG; I'm not sure Eliot
>was at that meeting.  At that time our thinking was along the lines of:
>
> - there are lots of useful things that people want to use that are
>   not in 10646, and

Sure are!

> - if you want to use such a character, or your particular display
>   machinery doesn't support some character for any reason, if all you
>   have is a number, there's not much you can do; an ancillary string
>   might well support table lookup, or at the very least enable a
>   coherent error message, so

Sure does!

> - people use SDATA to provide a string to help out with this, but

Sure do!

> - this was not what SDATA was meant for, says Charles among others, and

Given the above, who cares?

> - the syntax of said strings, and the manner of their implementation, is 
>   wildly different from vendor to vendor and from app to app, and
But if we reserve a syntax for an eventual standard method, the first two
points carry more weight and objections about the "best" solution lose
force, as we can punt on that safely while improving the ordinary user's
lot, by eliminating a class of annoying and unrecoverable behavior. (A
number is _never_ better than a string).

> - James pointed out that if what you really need is a string
>   associated with a particular character, then there should be a facility
>   for this, e.g. an attributed character reference, rather than 
>   kludging our way through with SDATA, and furthermore

This might as well be implemented by SDATA, given that SDATA is already used
that way, and given that we don't otherwise need SDATA (agreed by all I
think). 

> - we really didn't have time in the V1.0 timeframe to figure out what
>   the right solution is, and finally
But we don't need to..

> - XML was already getting too big.

Is this really that much? One keyword, and no mandatory processing other
than to display it to the user if you don't choose to implement some more
complex strategy.

>
>So we [nearly unanimously, as I recall] decided to leave this problem
>unsolved in V1.0.  Sorry.

I take the point, but given that I think the arguments against SDATA are
specious, I feel compelled to drag us through the damn thing one more time.
We don't have to pick an optimal solution to significantly improve XML, in
this case; we don't lose compatibility with SGML as defined, and actually
retain it with SGML as practiced.

>Cheers, Tim Bray
Well, no cheers here, I'm afraid.

  -- David

We can't even represent the musician who used to be known as Prince, who can
truly claim:
"I am not a number, I am an undefined character!"

Received on Monday, 9 December 1996 19:47:46 UTC