Re: ICC update from Tom Lianza, Chairman ICC.
Re: ICC update from Tom Lianza, Chairman ICC.
- Subject: Re: ICC update from Tom Lianza, Chairman ICC.
- From: Graeme Gill <email@hidden>
- Date: Thu, 18 Nov 2010 23:47:05 +1100
edmund ronald wrote:
XML just provides the scaffolding.
The lookup tables can be encoded as an ASCII blob or as an array of floats.
My points remain: it blows the filesize up significantly, and if the values
are encoded to save some space, they aren't easily understandable or
editable.
[ XML: the worst of both worlds. Too machine oriented and verbose to be
easily comprehended by humans, and too bulky to be an efficient file
format that can be quickly parsed by computers.]
The big advantage of XML is that you don't have to spend years of your
life writing the parser, and updating it every time the spec changes.
This is simply not true. It's almost exactly the same, in that any decent
implementation of an ICC parser has a library of parsing elements that
can trivially and robustly parse the binary stream, and all the work is
in understanding what you've parsed, just as is the case with XML.
The parser itself gets the benefit of al the publicly available XML
libraries. In case you hadn't noticed XML has taken the world by storm
precisely because it takes the sting out of engineering the writing
and reading data to file.
There's nothing special about XML in this regard. Just because it's
popular, doesn't make it right for everything: XML is well suited to
being a markup language, it is not well suited to being a data storage format.
Another example to add to lack of binary representation: It has no easy way
of sharing data elements. You either have to duplicate them, or concoct a
fudge to do it.
[Take a look at how SOAP is doing: sure there was much enthusiasm at the start,
but now the gloss has gone off it, because it's slow, because it's in XML.]
Another big advantage of XML is that the ICC should be writing the
DTD. Thus the spec would defacto define the XML parser; the ICC itself
would be doing the work for all engineers using the format, and all
parser implementations would be conformant.
I suggest you take a look at some of the other "marvels" of XML in the
color and printing area, such as the CxF 2.0 format (about 4 x as complex
as it needs to be), or if you really want to see how out of control it can get,
take a look at the JDF (Job Description Format), well over 1000 pages of
bewildering file format spec., all to be encode in XML! Easy to parse,
a whole lot of work to actually use for anything, and I bet the interchangability
is quite poor, simply because it is so vast, and XML makes it far too flexible.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden