RE: [xml-dev] Partyin' like it's 1999

["Derek Denny-Brown" <derekdb@microsoft.com>]

> -----Original Message-----
> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> 
> > For documentation, Derek cites (in his order significant or not):
> >
> > 1. Allowed characters
> 
> Hi! I don't think Derek's stated comments on allowed characters
> are correct.
> 
> He says that XML only allows letters and digits in names, which
> is not so. He says that there have been lots of Asian characters
> missed out, which is not so. 

I over simplified my description of what characters are allowed in
names, agreed.  I have been told by some of our customer reps that the
allowed character range for names has been a blocking issue for some
Asian customer.  It may be that it is only one key character which is
causing the problem, or it may be an entire class of characters.  I only
know that it is blocking customer adoption.

> And he says that XML required
> checking for correct surrogate pairs, which is not so.

XML 1.0 had surrogate pairs.  The Unicode 2.0 code-point space was
32-bit.  It might be better to argue that surrogate checking is a side
effect of the lamentable decision by Microsoft (and others.. java for
example) to choose UTF-16 as their primary encoding for Unicode
characters.

> As another matter, Derek mentions spurious whitespace nodes. But if
> using a DTD (and validating parser) these nodes will not
> be generated. So it is not a problem with XML, but a trade-off
> you get with using simple XML. Indeed, even with no-DTD XML, people
> can avoid spurious whitespace nodes simply by not autoindenting
> their generated XML. XML Schemas and RELAX NG also provide
> enough information that a vendor could use to configure their
> XML processors to strip out insignificant whitespace.

While true, I find that significant portion of my customers do not use
DTD/XSD/Relax-NG, and have no real desire to introduce that extra
complexity.  If we could have made it easier to indicate when whitespace
was ignorable for no-DTD XML, these customers would have had fewer
problems.

-derek