Re: OpenDocument. Was: Photoshop PSD 6 format Spec / Gimp XCF formatSpec

> I have feeling that packaging graphics "document" in a zip file is
> overkill
> _similar_ to doing that with database "document", in terms of
> saving/loading
> time and disk space needed for loading/saving. Think about _large_
> documents.
>

I think this depends upon what you mean with database respective graphics
"document".
A XML format where the actual data is stored as XML is indead rather
uneffective, because there exist better way to store (from top of my head
something like CSV with column data, or perhaps even some
"semi-documented" table storage format like dBase.
Storing all elements which "belong" to a database - i.e. the forms,
indexes, stored queries and such makes much more sense. In this case you
store only the "table of contents" as XML. The actual "document leaves"
are stored as XML as seen fit.
I.e. it doesn't make sense to invent a new document format for database
forms if you can instead use a XML grammar / DTD.

I think you could use a similar distinction for graphics documents. Store
the actual images / layers in a binary format, and the rest of the data
(brush definitions, path definitions,  information about how the layers
are mixed, such kind of stuff, as XML if feasible.

> I'd like to propose use well documented binary format, e.g. using Binary
> XML.
>
> http://www.w3.org/TR/xbc-use-cases/#intro
>
> I wonder why OASIS picked to only use compressed XML as a medium:
> -it will also not work well for video data, BTW.
> -OpenOffice.org Base already failed to deliver robust solution because
> 100% of
> the data has to be processed on loading/saving (unless it's stored on the
> server).
>

I am rather ambivalent about binary XML. IMHO it is a workaround around
stupidly designed / bloeated DTD's / schemas.
If you design a good DTD schema, even with some custom sub grammar, like
the path definition for SVG, you kan keep the size of your XML documents
small without having to resort to binary encoding.

> Or, any chances to join forces with GIMP and their XCF format? Ideally,
> I'd
> see both projects moving to binary (read: extendable) XML. Even sticking
> with
> another iteration of XCF, as a container seems better. Eventually, you can
> always append a chunk of XML data (metadata) to such a binary block _in
> place_
> ang get really good performance.

From what I understand, XCF has no way to store non RGB(A) buffer data
because GIMP internally don't support non-RGBA buffers. I think this would
make adoption rather problematic for Krita.

> What's wrong with text XML in Calc is that Calc is used by some
> of the users as a database medium, what's terible but it's true.

I don't think it is terrible, indeed I am just such a user ;)
A spreadsheet application is fine if you have list data which are not yet
schematized and normalized.
You can add attributes as you see fit instead of jumping through hoops as
in  desktop database application.
And you can do some basic stuff like reordering or searching per column.

If the data is "ready", you export per CSV or TSV and re-use the data in
some proper "database" application, be it desktop based or a proper server
database.

Regards
Dirk