Re: XML GNUstep defaults (was: [flame] NEWS file is useless)

[Lars Sonchocky-Helldorf]

Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:

> On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
>
> > Richard Frith-Macdonald wrote:
> >
> > > > I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
> > > > That's XML for me now and it wasn't.
> > >
> > > Oh, that's a hidden file for private use by the base library ...  
> > > kind of surprising that anyone would notice, and certainly not  
> > > something which should appear in news/release notes as it's  
> > > internal information.
> >
> > Indeed, one shouldn't notice -- except that there was a bug in  
> > NSPropertyList.m, which did use an incorrect translation for ASCII  
> > control characters (it was using the old Java \Uxxxx notation  
> > instead of numerical character encodings). Due to this bug the  
> > position of menus was no longer persistent. I've just committed a  
> > fix for this in svn and now torn-off menus will reappear again the  
> > next time you start an app.
>
> I partially reverted that ... the code to generate the escape  
> sequences was correct, the problem was a failure to parse them on  
> reading the result back.
>
> The underlying issue is that certain characters are illegal in XML,  
> even when encoded using the &#...; syntax!
> The list of illegal characters includes ascii code 27 (escape), yet  
> OSX uses the escape character as the key for the top-level menu.
> If you feed such data to a proper XML parser (such as libxml2), it  
> will abort parsing when it encounters the illegal character.

Isn't that a bug?

http://www.w3.org/TR/xml11/#sec-xml11 says that "Finally, there is  
considerable demand to define a standard representation of arbitrary  
Unicode characters in XML documents. Therefore, XML 1.1 allows the  
use of character references to the control characters #x1 through  
#x1F, most of which are forbidden in XML 1.0. For reasons of  
robustness, however, these characters still cannot be used directly  
in documents."

Or are xml-plists still based on XML 1.0?

> If we assume that 'XML' property lists will never actually be  
> processed by real XML parsers, we don't need the additional encoding.

One never knows, maybe at one day somebody wants to write some sort  
of converter using XSLT. Locking out XML tools makes the whole idea  
of using XML for plists somewhat pointless

<rant>
I think the old or "classic" format is much better readable and less  
verbose - and nowadays after the XML hype people start using JSON  
( http://en.wikipedia.org/wiki/JSON ) for formerly XMLish purposes  
which is a lot like the classic plist format.
</rant>

regards,

        Lars