[Openicc] meta data in test chart

[Alastair M. Robinson]

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