The next file format

[Inge Wallin]

On Monday, August 18, 2014 13:09:02 Andreas Xavier wrote:
> Hello,
> 
> I would like to do 2 things in this email, bring up versioning of the file
> specification and attach an XML schema that I put together to promote
> discussion. I will address other topics in the threads already started for
> them.

Yes, versioning of the file format is probably important. The only thing we need to be 
careful about at this stage is that we design in this feature. Then, later, we also need to 
make sure that the features themselves will be extensible.

> I think that we need a plan to version the file specification.
> We are unlikely to anticipate and solve all future problems with the file
> format. KVTML is evidence that the file format places hard to circumvent
> restrictions on the future functionality of the applications it is used
> for.
> 
> I do not know what the correct solution is but here are some suggestions:
> 
> + Put version information in the file and maintain backward compatibility
> with all readers. This solution has the disadvantage that old readers
> completely fail with new file formats.

Unless you write the readers to just disregard any unknown content. As long as you 
maintain backward compatibility for the old parts of the spec that should be no problem.

> + Spend a long time in alpha/beta
> 
> + Make as many tags as possible optional and have readers ignore
> unrecognized tags.  This is close to KDE's binary compatibility
> restrictions on APIs.  Old readers will be able to read new files, but will
> only provide their old functionality.

Yes, I think this is the way to go.

> I have attached an XML schema that I sent to Inge.  This was NOT intended to
> be used as is.  This is not an endorsement of XML.  I think XML is noisy,
> fragile and intimidating to non-programmers, but it is ubiquitous and has
> canned reader/writers.

I will disregard the xml scema completely right now, since it's not relevant for the topics 
of this thread. Except this specific that I get from what you say above: You don't really 
want XML. This seems to be consistent with Bruno, Andreas CoLa and maybe even more 
people.

> The example xsd is only monolithic because it was easy to edit.
> I expected that each of the major sections would be broken out into a
> separate section/file in the zip: information, overlays, structure (words
> and grammar), coursePlan and user.
> 
>  The overlays idea is taken from artikulate's skeleton idea.
> CoLa's code is beautiful and well organized (,needed to be said). If I
> misrepresent this concept I apologize.

Can you describe a little more about this overlays thing? I tried to find something about it 
in the thread but didn't manage to do it. Maybe in a separate thread, though, so we can 
keep this one focussed.

	-Inge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20140822/6b977ae3/attachment-0001.html>