[WF-Protocols] Summary of proposed file serializations

[Matze Braun]

On Wed, 2 Jul 2003, Aglanor wrote:

> Here's a summary of the proposed file serializations for the Open Model
> Format as of today:
> 
> * XML: human readable, for development and debugging. Lots of tools
> around.
And I must agree with Jorrit here! xml is THE standard we'll get lots of 
parser, and stuff like validators or xslt for free! That'll simply save us 
lots of development time and will make the life alot easier for users. (As 
a user you can hack converters in any language you want, I dunno any 
language which has no xml parser yet)

> 
> * IFF: binary, compact, efficient, proposed standard.
> 
> * YAML: human readable, more compact than XML.
> 
> * Bach: human readable, more compact than XML.
Though intersting they're all far away from the acceptance level of xml. 
Anyway some more points about the format:

-If we keep to a simple DOM it shouldn't matter which one we use and we  
 should be able to switch easily later.
-PLEASE don't think about efficiency now!!! This format should be 
 extensible and easy to write and parse which often is the contrary to 
 efficiency. Flexibility should be top priority! I don't want to trade 
 good design for efficiecy.
-This format should be an exchange format not a native format IMO, as it 
 can't be efficient as a native format anyway:
	-In a generalized file data will most probably not arrive the 
	 order the 3d engine expects it. This will result in jumping 
	 around in the file while reading or huge memory usage and 
	 caches.
	-As the format is general it might contain features that the 
	 engine can't use directly. (Some simple examples: double sided 
	 faces, UV coordinates attached to vertices instead of faces,
	 some transforms aren't supported by the engine). These things 
	 would need to be converted again while loading.

So we should really focus on an exchange format IMO. Regarding the file 
format as a native one is an error, the engines should better stay with 
their own formats.

> 
> ***********************
> 
> 	I'd like to note that given a data structure, any serialization is
> possible, and translations between them, while keeping the information
> intact, so IMHO we should just focus on decide just two for the model
> format design:
> 
> 	- one human-readable for initial development and debugging.
> 
> 	- one final, most efficient format which will be used in practice.
As noted above, I'd also use xml for final format (maybe put in a 
zipfile...) Every other solution will need alot more work for writing 
parsers. Efficiency for an exchange format isn't that important.

> ...

Greetings,
	Matze