[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: Richard Frith-Macdonald
Subject: Re: XML GNUstep defaults (was: [flame] NEWS file is useless)
Date: Fri, 27 Nov 2009 19:36:10 +0000

On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote:

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

No ... it's what the XML spec says.

> 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."

That's really interesting ... I didn't know that this was changed for XML 1.1

> Or are xml-plists still based on XML 1.0?

Yes ... they pre-date XML 1.1.

Here's the header of a property list copied from my (snow-leopard) OSX system:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD 
PLIST 1.0//EN" "";><plist 

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

Perhaps we can change to using XML 1.1 for our plists?

> <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 ( 
> ) for formerly XMLish purposes which is a 
> lot like the classic plist format.
> </rant>

Yes, the old plist is better in almost every way (addition of date, boolean, 
and numeric types were good extensions though).

I just tried an experiment on OSX.

I copied an existing OSX XML property list, edited it with vi, and set the xml 
version in the header to 1.1 rather than 1.0
I then opened it in the 'Property List Editor' application ... it opened 
perfectly well and I was able to make a small edit.
I then saved it ... the saved output has the '1.0' version header again.

So it looks like OSX can read XML 1.1 but still writes 1.0

If there's no problem with OSX reading it ... I see no real reason why we can't 
update our plist code to output XML version 1.1 rather than 1.0 ... the only 
worry then would be that older XML software, which didn't support version 1.1,  
might have trouble with it.  That's probably acceptable.

reply via email to

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