[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lars Sonchocky-Helldorf
Subject: Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
Date: Fri, 27 Nov 2009 19:28:39 +0100

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? 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

I think the old or "classic" format is much better readable and less verbose - and nowadays after the XML hype people start using JSON ( ) for formerly XMLish purposes which is a lot like the classic plist format.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]