Re: SDATA, again

At 02:35 PM 12/9/96 -0500, David J Birnbaum wrote:
>On Mon, 9 Dec 1996, David G. Durand wrote:
>
>> As XML stands we have the private use character codes, which provide no
>> resolution mechanism for determining which non-unicode character is
>> included in an instance. I am asking only that we repalce the numerical
>> values provided by private-use, with string values. We will still not
>> have a resolution mechanism, but we will have a foundation on which one
>> can be built.
>
>I joined this list only recently and was not part of the original
>discussion of SDATA. But wading in now, I do not see any significant
>disadvantages to David's proposal, let alone any that would outweigh the
>obvious advantages. Can someone fill me in on the arguments for the other
>side? And is there any procedural reason why this issue should not be
>reexamined? 

I believe our original reasoning against SDATA was as follows:

1. The mechanism for mapping SDATA replacement text to
characters/glyphs/whatever was not defined or definable.  This makes SDATA
entities inherently uninterchangable.
2. You could do everything you needed to do with SDATA by using CDATA
entities with 10646 character references (but this appears to not be true).
3. Leaving SDATA out significantly simplified the spec, putting it in
significantly complicated it.  Simple wins, as a rule.

Cheers,

E.
--
W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"

Received on Monday, 9 December 1996 15:48:50 UTC