Please be aware that SampleICC already includes an XML <=> ICC format capability. Any tags in an ICC profile can be edited in an XML editor using that capability for pre- and post- conversion. This obtains the XML text editing experience and at the same time retains the efficient storage format of the ICC profile. Best regards, Ann McCarthy Imaging Systems R&D Lexmark International, Inc. <table width=100%> <tr valign=top> <td width=40%>"Alastair M. Robinson" <blackfive@fakenhamweb.co.uk> Sent by: openicc-bounces+almccart=lexmark.com@lists.freedesktop.org 01/20/2011 09:24 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>edmund ronald <edmundronald@gmail.com> <tr valign=top> <td> <div align=right>cc</div> <td>OpenICC Liste <openicc@lists.freedesktop.org> <tr valign=top> <td> <div align=right>Subject</div> <td>Re: [Openicc] meta data in test chart</table> <table> <tr valign=top> <td> <td></table> </table> <tt>Hi, On 21/01/11 01:07, edmund ronald wrote: > I think we need to choose between XML and JSON. Robert will have final > say, I guess, but we might as well have it out there. I'm with Graeme in thinking XML is a horrible format to edit by hand (because the tags and the <> delimiters all have the same visual "weight" as the data within, so to my eyes it all just congeals into a mass on screen.)  However, despite my dislike of it, I think XML might be the better fit in this case. What needs to be able to parse the serialised options, and what can just treat it as a "blob"? * Gutenprint: Obviously needs to be able to both parse and write. * Oyranos, colord, etc.: Do they need to parse, or is a test for "equality" (for some yet-to-be-determined definition of "equality") sufficient? * ArgyllCMS: I would think profiling tools in general would need no awareness of the contents and would treat the data as a blob to be embedded in the final profile? > One argument in favor of JSON is that we can expect to write GUI's to > manipulate settings for the user so JSON is a good fit. From my experience using the Gutenprint options system from within PhotoPrint I'd say the options' limits and their interactions with each other are *way* too complicated to be encoded within a serialised options file, so a GUI tool to edit such a set of options would probably need to be linked with libgutenprint.  Such a tool (at least a Gutenprint-specific tool) would be far better off deserialising an options file into a live stp_vars_t, editing that, then serialising it again than attempting to parse a file itself and implementing its own internal model with option constraints.  Gutenprint already has an XML library, so I don't see much sense in making Gutenprint use a different parsing library just for option serialisation. All the best -- Alastair M. Robinson _______________________________________________ openicc mailing list openicc@lists.freedesktop.org </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc </tt></a>