On May 11, 2006, at 7:02 AM, Chapman Flack wrote:

> In defense of Jason's bikeshed -
> - it's using, IIUC, a strict subset of XML just adequate to export its
>  own stuff, so the only reason for it to set off anybody's XML-alarm
>  would be the spelling of its tokens, not the inherent complexity of
>  its parser.

That is correct.  It is not a general XML parser.  It parses only  
"property lists".

> - that presumably means that you couldn't expect proplib to parse
>  arbitrary output from XML tools, but you could expect existing
>  general purpose XML tools to do useful things with proplib output
>  if you wanted to.

Again, correct.

> - the choice was based, IIUC, on prior art from Apple. Even if that
>  has no direct technical benefit (this kind of device-dependent stuff
>  might never be exchanged between OSs), it still offers a kind of
>  conceptual harmony to people who might administer both NetBSD and OSX
>  machines.

Not just conceptual harmony for those who admin both (OS X admins  
don't fiddle with plists manually very often, if at all).  Basically,  
I saw Apple XML plists as prior art for a file format that was  
extremely flexible and human editable.  If I wanted to do it in some  
other markup language, I would have had to define another DTD- 
analogue, and honestly I didn't see the point in divergence for  
divergence's sake.  Besides, would a general YAML parser be smaller  
than my specialized plist parser?

Sure, Apple has other file formats for plists (like a very compact  
and fast-to-parse binary plist format), but they're not human  
readable / editable with standard text tools.  I could certainly  
entertain the idea of being able to externalize to / internalize from  
that format... but it is also desirable to keep the text form at the  
same time, for other reasons.

-- thorpej