On Wed, Nov 03, 2010 at 05:57:39AM +0000, David Holland wrote: > On Mon, Nov 01, 2010 at 08:00:09PM -0500, David Young wrote: > > I'm working on a library called ppath(3) for making property lists more > > convenient to use in the kernel. With ppath(3), you refer to a property > > to read/write/delete in a property list by the path from the list's > > outermost container. Comments welcome. > > Speaking from the POV of someone who's been working on querying > semistructured data for several years now... I have a pile of > high-level questions: (1) can you articulate the expressive power you > intend for your path expressions, and why that's a logical stopping > point vs. more expressive things;
I want to index individual elements in a property list using succinct and reliable C code. Ideally, I would be able to treat a property dictionary/array as a C struct/array and use an expression such as "a[i].b.c.d[j]". It's a logical stopping point because it meets my needs. (2) what if any facilities do you > envision for checking paths against proplist schemas when/if we ever > manage to sort out a system for that; None. > (3) what model do you have for > dealing with cases when the values found at the paths provided are not > what the user is expecting; and ppath(3) routines return EFTYPE if the application code tries to read one type (e.g., bool) from a path and ppath(3) finds another (e.g., number) at that path. Beyond that, it's up to the application. > (4) what model do you have for dealing > with cases where the path does not name a single unique value or > position, if that's possible? That's not possible. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933