xml microtonal file format collaboration proposal

As I've been looking into file formats lately (.scl, .kbm, .tun) as well as fiddling around with some file database work (for .cse and .tpx files), I've had the thought that .scl .kbm and .tun are (in terms of their structure) a bit out of date and they would be a whole lot more attractive for developers if they were in xml format.

Manuel and Mark, is there any chance you would want to either make new xml versions of .scl and .tun file formats?

Maybe better, would you want to collaborate on a new xml format which could cover all the bases, and then some, which you would support in your software? Programmers on this list could likely give a lot of good input for building something of an ideal format. Generally speaking, xml file format would be the up-to-date structure, it would allow easy database indexing and searching, and would allow for a variety of approaches to scale definition. For example, something missing from existing formats is a way to specify MIDI notes in Hz values (which is what I initially thought .tun was). My formats .cse and .tpx allow for all kinds of pitch definition, but they also contain loads of application-specific data.

Anyway, I thought I would throw the idea out there. If nobody is interested, I'll just do it myself.

Cheers,
Aaron Hunt
=====

Hey other-Aaron,

This is a cool idea, and one I think that ultimately needs to be done.
The only problem is the age-old 'legacy problem', where as un-ideal as
older solutions are, most existing software now uses them!

-AKJ

--- In tuning@yahoogroups.com, Aaron Andrew Hunt <aaronhunt@...> wrote:
>
> As I've been looking into file formats lately (.scl, .kbm, .tun) as
> well as fiddling around with some file database work (for .cse
> and .tpx files), I've had the thought that .scl .kbm and .tun are (in
> terms of their structure) a bit out of date and they would be a whole
> lot more attractive for developers if they were in xml format.
>
> Manuel and Mark, is there any chance you would want to either make
> new xml versions of .scl and .tun file formats?
>
> Maybe better, would you want to collaborate on a new xml format which
> could cover all the bases, and then some, which you would support in
> your software? Programmers on this list could likely give a lot of
> good input for building something of an ideal format. Generally
> speaking, xml file format would be the up-to-date structure, it would
> allow easy database indexing and searching, and would allow for a
> variety of approaches to scale definition. For example, something
> missing from existing formats is a way to specify MIDI notes in Hz
> values (which is what I initially thought .tun was). My formats .cse
> and .tpx allow for all kinds of pitch definition, but they also
> contain loads of application-specific data.
>
> Anyway, I thought I would throw the idea out there. If nobody is
> interested, I'll just do it myself.
>
> Cheers,
> Aaron Hunt
> =====
>

--- In tuning@yahoogroups.com, "Aaron Krister Johnson" <aaron@...> wrote:
>
> Hey other-Aaron,
>
> This is a cool idea, and one I think that ultimately needs to be done.
> The only problem is the age-old 'legacy problem', where as un-ideal as
> older solutions are, most existing software now uses them!
>
> -AKJ
>

(Botched first reply, trying again!)

Hey AKJ! Quite right! And it would take time to get developers to
move over to a new format. But, phasing out the old and phasing
in the new could take place over a period of years if new files are
saved in a new format, and the new format is the only one some
leading software *opens* files in, (importing and exporting
the old formats would persist - converting over to the new could
take a decade), and this is exactly why I hope to persuade Manuel
and Mark to consider taking this path.

Still, you're absolutely right... it's a cart before the horse problem.

- AAH
=====

> --- In tuning@yahoogroups.com, Aaron Andrew Hunt <aaronhunt@> wrote:
> >
> > As I've been looking into file formats lately (.scl, .kbm, .tun) as
> > well as fiddling around with some file database work (for .cse
> > and .tpx files), I've had the thought that .scl .kbm and .tun are (in
> > terms of their structure) a bit out of date and they would be a whole
> > lot more attractive for developers if they were in xml format.
> >
> > Manuel and Mark, is there any chance you would want to either make
> > new xml versions of .scl and .tun file formats?
> >
> > Maybe better, would you want to collaborate on a new xml format which
> > could cover all the bases, and then some, which you would support in
> > your software? Programmers on this list could likely give a lot of
> > good input for building something of an ideal format. Generally
> > speaking, xml file format would be the up-to-date structure, it would
> > allow easy database indexing and searching, and would allow for a
> > variety of approaches to scale definition. For example, something
> > missing from existing formats is a way to specify MIDI notes in Hz
> > values (which is what I initially thought .tun was). My formats .cse
> > and .tpx allow for all kinds of pitch definition, but they also
> > contain loads of application-specific data.
> >
> > Anyway, I thought I would throw the idea out there. If nobody is
> > interested, I'll just do it myself.
> >
> > Cheers,
> > Aaron Hunt
> > =====
> >
>

Dear Aaron,

On Dec 20, 2008, at 2:13 PM, Aaron Andrew Hunt wrote:
> As I've been looking into file formats lately
>
> Manuel and Mark, is there any chance you would want to either make
> new xml versions of .scl and .tun file formats?

There are some pros and cons to XML in general. For example, XML has a relatively simple syntax and is widely used, but more simple formats are even more easy to parse and XML tends to be more verbose than other formats.

Some link to a discussion on file formats is here (not music related at all), just the pointer I came up with sontaneously, there is certainly more in depths info on this matter.

http://www.catb.org/~esr/writings/taoup/html/ch05s02.html

Best
Torsten

--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
Office: +44-1752-586219
Private: +44-1752-558917
http://strasheela.sourceforge.net
http://www.torsten-anders.de

Hi Torsten.

I anticipated possible disagreement on xml as the best format.
<http://en.wikipedia.org/wiki/Xml>
Although the formats of .scl and .tun are already simpler then
xml and work great as long as the parser knows the rules,
some important advantages specifically which I see form xml are:

(1) it is verbose

I suppose the only objection to this is file size. Otherwise I can't
think of a reason that this is a bad thing. Being verbose does not
guarantee an easily human-readable file, but if the markup is
declarative enough, the file *can be* completely human readable and
clear as day as to what it is this file is about and what is going on
in it. I feel this is particularly important for microtonal stuff as the
whole business is so extremely confusing, and if there is nothing
to tell you what this number means or what units you are talking
about, then the data is per se completely meaningless.

(2) it is extensible

A format should be ready for future expansion, and xml is perfect
for that. If you want new data added, just add new tags with or
without new attributes and put data in there. If you want,
Document Type Definition headers can even be used to identify,
validate, and keep files up to date

(3) parsing xml is super easy

If the parser doesn't look for it, there is no error. If the parser
looks for it and it is not there, there is also no error. If the markup
is clear and human readable, then it will be clear to any programmer
what to do with the data.

I am by no means a computer scientist, and in fact I do not have any
formal training in computer programming; therefore I wonder if you
can speak to the points I make above, correct anything that is wrong,
and help me understand why something else may be a better choice
for a format than xml.

Thank you!
Aaron Hunt
=====

--- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@...> wrote:
>
> Dear Aaron,
>
> On Dec 20, 2008, at 2:13 PM, Aaron Andrew Hunt wrote:
> > As I've been looking into file formats lately
> >
> > Manuel and Mark, is there any chance you would want to either make
> > new xml versions of .scl and .tun file formats?
>
>
> There are some pros and cons to XML in general. For example, XML has
> a relatively simple syntax and is widely used, but more simple
> formats are even more easy to parse and XML tends to be more verbose
> than other formats.
>
> Some link to a discussion on file formats is here (not music related
> at all), just the pointer I came up with sontaneously, there is
> certainly more in depths info on this matter.
>
> http://www.catb.org/~esr/writings/taoup/html/ch05s02.html
>
> Best
> Torsten
>
> --
> Torsten Anders
> Interdisciplinary Centre for Computer Music Research
> University of Plymouth
> Office: +44-1752-586219
> Private: +44-1752-558917
> http://strasheela.sourceforge.net
> http://www.torsten-anders.de
>

BTW everyone, I hope it does not appear that I am breaking my
promise not to discuss H-Pi stuff here. I'm happy to move the
topic to my own forum, but I would prefer an open discussion
here, because I want outside collaboration on this and I hope
you see it concerns more than just my business agenda.

Thanks,
Aaron H
=====

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aaronhunt@...> wrote:
>
> Hi Torsten.
>
> I anticipated possible disagreement on xml as the best format.
> <http://en.wikipedia.org/wiki/Xml>
> Although the formats of .scl and .tun are already simpler then
> xml and work great as long as the parser knows the rules,
> some important advantages specifically which I see form xml are:
>
> (1) it is verbose
>
> I suppose the only objection to this is file size. Otherwise I can't
> think of a reason that this is a bad thing. Being verbose does not
> guarantee an easily human-readable file, but if the markup is
> declarative enough, the file *can be* completely human readable and
> clear as day as to what it is this file is about and what is going on
> in it. I feel this is particularly important for microtonal stuff as the
> whole business is so extremely confusing, and if there is nothing
> to tell you what this number means or what units you are talking
> about, then the data is per se completely meaningless.
>
> (2) it is extensible
>
> A format should be ready for future expansion, and xml is perfect
> for that. If you want new data added, just add new tags with or
> without new attributes and put data in there. If you want,
> Document Type Definition headers can even be used to identify,
> validate, and keep files up to date
>
> (3) parsing xml is super easy
>
> If the parser doesn't look for it, there is no error. If the parser
> looks for it and it is not there, there is also no error. If the markup
> is clear and human readable, then it will be clear to any programmer
> what to do with the data.
>
> I am by no means a computer scientist, and in fact I do not have any
> formal training in computer programming; therefore I wonder if you
> can speak to the points I make above, correct anything that is wrong,
> and help me understand why something else may be a better choice
> for a format than xml.
>
> Thank you!
> Aaron Hunt
> =====
>
>
>
> --- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@> wrote:
> >
> > Dear Aaron,
> >
> > On Dec 20, 2008, at 2:13 PM, Aaron Andrew Hunt wrote:
> > > As I've been looking into file formats lately
> > >
> > > Manuel and Mark, is there any chance you would want to either make
> > > new xml versions of .scl and .tun file formats?
> >
> >
> > There are some pros and cons to XML in general. For example, XML has
> > a relatively simple syntax and is widely used, but more simple
> > formats are even more easy to parse and XML tends to be more verbose
> > than other formats.
> >
> > Some link to a discussion on file formats is here (not music related
> > at all), just the pointer I came up with sontaneously, there is
> > certainly more in depths info on this matter.
> >
> > http://www.catb.org/~esr/writings/taoup/html/ch05s02.html
> >
> > Best
> > Torsten
> >
> > --
> > Torsten Anders
> > Interdisciplinary Centre for Computer Music Research
> > University of Plymouth
> > Office: +44-1752-586219
> > Private: +44-1752-558917
> > http://strasheela.sourceforge.net
> > http://www.torsten-anders.de
> >
>

Dear Aaron,

I am probably not the right one to react in this matter. After all, you are interested in a collaboration with Manuel and Mark. I only meant to through in my 2 cents.

Concerning your questions, the document I linked to addressed them already. For example, parsing XML is indeed easy in principle, but you need a parser to do it, otherwise it is rather hard. For the current Scala file format you do not need a parser, it is fully sufficient your program knows that it should ignore the comments (lines starting with an exclamation marks and first non-comment line), read the number of notes, and then the actual pitches.

XML does not need any defending, it is of course a highly established format. Whether it is suitable depends on your application. E.g., do you want to process these files in some general programming language with an XML parser available, or do you also want to extract and process information in these files, say, in a UNIX pipe where XML would make things more complex.

Best
Torsten

On Dec 20, 2008, at 4:28 PM, Aaron Andrew Hunt wrote:

> Hi Torsten.
>
> I anticipated possible disagreement on xml as the best format.
> <http://en.wikipedia.org/wiki/Xml>
> Although the formats of .scl and .tun are already simpler then
> xml and work great as long as the parser knows the rules,
> some important advantages specifically which I see form xml are:
>
> (1) it is verbose
>
> I suppose the only objection to this is file size. Otherwise I can't
> think of a reason that this is a bad thing. Being verbose does not
> guarantee an easily human-readable file, but if the markup is
> declarative enough, the file *can be* completely human readable and
> clear as day as to what it is this file is about and what is going on
> in it. I feel this is particularly important for microtonal stuff > as the
> whole business is so extremely confusing, and if there is nothing
> to tell you what this number means or what units you are talking
> about, then the data is per se completely meaningless.
>
> (2) it is extensible
>
> A format should be ready for future expansion, and xml is perfect
> for that. If you want new data added, just add new tags with or
> without new attributes and put data in there. If you want,
> Document Type Definition headers can even be used to identify,
> validate, and keep files up to date
>
> (3) parsing xml is super easy
>
> If the parser doesn't look for it, there is no error. If the parser
> looks for it and it is not there, there is also no error. If the > markup
> is clear and human readable, then it will be clear to any programmer
> what to do with the data.
>
> I am by no means a computer scientist, and in fact I do not have any
> formal training in computer programming; therefore I wonder if you
> can speak to the points I make above, correct anything that is wrong,
> and help me understand why something else may be a better choice
> for a format than xml.
>
> Thank you!
> Aaron Hunt
> =====
>
> --- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@...> > wrote:
> >
> > Dear Aaron,
> >
> > On Dec 20, 2008, at 2:13 PM, Aaron Andrew Hunt wrote:
> > > As I've been looking into file formats lately
> > >
> > > Manuel and Mark, is there any chance you would want to either make
> > > new xml versions of .scl and .tun file formats?
> >
> >
> > There are some pros and cons to XML in general. For example, XML has
> > a relatively simple syntax and is widely used, but more simple
> > formats are even more easy to parse and XML tends to be more verbose
> > than other formats.
> >
> > Some link to a discussion on file formats is here (not music related
> > at all), just the pointer I came up with sontaneously, there is
> > certainly more in depths info on this matter.
> >
> > http://www.catb.org/~esr/writings/taoup/html/ch05s02.html
> >
> > Best
> > Torsten
> >
> > --
> > Torsten Anders
> > Interdisciplinary Centre for Computer Music Research
> > University of Plymouth
> > Office: +44-1752-586219
> > Private: +44-1752-558917
> > http://strasheela.sourceforge.net
> > http://www.torsten-anders.de
> >
>
>
>

--- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@...> wrote:
>
> Dear Aaron,
>
> I am probably not the right one to react in this matter. After all,
> you are interested in a collaboration with Manuel and Mark. I only
> meant to through in my 2 cents.

OK, but I respect your input highly especially as I know computer
science is your field. I was only informally tutored at a young age in
computer programming and then learned more on my own much
later, so I have huge gaps in my knowledge that I just fill in when I
need to, and then not in any formal way. So I'm probably not the best
candidate to come up with a new file format, but if I thought that way
then I would never do anything, and anyway we are all unlikely
candidates in this or that way...

> Concerning your questions, the document I linked to addressed them
> already. For example, parsing XML is indeed easy in principle, but
> you need a parser to do it, otherwise it is rather hard. For the
> current Scala file format you do not need a parser, it is fully
> sufficient your program knows that it should ignore the comments
> (lines starting with an exclamation marks and first non-comment
> line), read the number of notes, and then the actual pitches.
>
> XML does not need any defending, it is of course a highly established
> format. Whether it is suitable depends on your application. E.g., do
> you want to process these files in some general programming language
> with an XML parser available, or do you also want to extract and
> process information in these files, say, in a UNIX pipe where XML
> would make things more complex.

I really don't know enough about that to comment. As far as I know
it is very easy to write an XML parser just using string manipulation,
with just a few methods to find tags and attributes and get the values,
and whatever is done with that data is app-specific. The main point
for me is that the file should be totally human readable and requires
absolute minimum of explanation for some developer to implement it.
My own usage of XML so far has been quite pseudo, and the files
contain app-specific data and character delimited strings within tags
and all kinds of things which are not good for XML generally, but I
can see a well formed XML which will bring all these things in tuning
files which are so confusing finally into the light of day, and I think
if that happens and it is used, then it will be a huge step forward for
the future of tuning implementation in software.

Of course it's just my opinion.

Yours,
Aaron H
=====

--- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@...> wrote:
> > Manuel and Mark, is there any chance you would want to either make
> > new xml versions of .scl and .tun file formats?
>
> There are some pros and cons to XML in general. For example,
> XML has a relatively simple syntax and is widely used, but more
> simple formats are even more easy to parse and XML tends to
> be more verbose than other formats.

I've always thought s-expressions would have been better for
the job. -Carl

--- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aaronhunt@...>
> (1) it is verbose
>
> I suppose the only objection to this is file size.

There is another -- it's harder to write (type). One nice
thing about .scl is that is works well as a literary format,
human readable AND writable.

Also, for posting on mailing lists and such, some bulletin
board systems strip out SGML tags, which would make it
harder to share scales.

I also like the abstraction Scala files provide -- I don't
think concert pitch information (let alone Hz. values for
each note) is best stored with the intervals of the scale.

That said there are some advantages to XML... mainly
industry adoption -- heh! I'll turn that around on you,
Aarons! But anyway, just being contrary as usual I guess.

-Carl

2008/12/21 Carl Lumma <carl@...>:
> --- In tuning@yahoogroups.com, Torsten Anders <torsten.anders@...> wrote:
>> > Manuel and Mark, is there any chance you would want to either make
>> > new xml versions of .scl and .tun file formats?
>>
>> There are some pros and cons to XML in general. For example,
>> XML has a relatively simple syntax and is widely used, but more
>> simple formats are even more easy to parse and XML tends to
>> be more verbose than other formats.
>
> I've always thought s-expressions would have been better for
> the job. -Carl

They're both essentially the same, and good for hierarchical data
structures. Where's the hierarchy in tuning files? They're lists of
pitches. I don't see the point.

Graham

I see XML tags the same way I see HTML tags. There are all kinds
of tags available, but that does not mean you use them all in one
document. You don't need to store Hz values with interval
data. Using the tags in ways that don't make sense would
just produce a wrong result. The idea is that there is some tag
for Hz values and there is another for intervals of whatever type,
and whatever you want to use will be understood by the parser
according to the Document Type Definition. There could even
just be a <SCALA> tag within which is placed normally
formatted .scl file data.

Yours,
Aaron H.
=====

--- In tuning@yahoogroups.com, "Carl Lumma" <carl@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Andrew Hunt" <aaronhunt@>
> > (1) it is verbose
> >
> > I suppose the only objection to this is file size.
>
> There is another -- it's harder to write (type). One nice
> thing about .scl is that is works well as a literary format,
> human readable AND writable.
>
> Also, for posting on mailing lists and such, some bulletin
> board systems strip out SGML tags, which would make it
> harder to share scales.
>
> I also like the abstraction Scala files provide -- I don't
> think concert pitch information (let alone Hz. values for
> each note) is best stored with the intervals of the scale.
>
> That said there are some advantages to XML... mainly
> industry adoption -- heh! I'll turn that around on you,
> Aarons! But anyway, just being contrary as usual I guess.
>
> -Carl
>

--- In tuning@yahoogroups.com, "Aaron Krister Johnson" <aaron@...> wrote:
> The only problem is the age-old 'legacy problem',
> where as un-ideal as older solutions are, most
> existing software now uses them!

Full ACK. Any new format will fail if there is no software which
supports it.

Besides that, someone in this thread mentioned, writing a XML parser
would be thus easy. O.K., then do it. I'm not in the details of XML.
I'm sure that I could create some format description which would look
similar to XML, but I don't know the standards of XML to ensure that
it _is_ a valid XML file.

That's why I keep my hands away from XML in general.

And: If you wrote a XML parser, take the source an compare it with
e.g. my sources of the .tun format. I assume, that the XML source would be
a) overwhelming in size
b) rather complicated which may prevent developers from using it (keep
in mind that they may have to port it to another programming language!)

That's why I expect problems when creating a complex format.

But nevertheless, I agree that the .tun standard could have some
improvements. But downwards compatibility will be the main task to
make the developers and users accepting it.

Furthermore, this Yahoo group is not the right place for these
discussions, as there are too few developers presented. But they
should, as they have to implement it in their code and they have to
understand *why* they should implement it.

I think, a better place for this discussion is the kvraudio site, as
there are lot of users and developers.

When revising the .tun specifications I will post there some
suggestions for a version 2 (I can drop a note here, if you wish).
Things I would include is:

- Definition of middle key
- Parameters for side information as e.g. scale name, creator,
software used, additional informations/comments
- I will also discuss the further need of the [Tuning] section. Maybe
this downward compatibility is no longer needed and can be dropped.
- Considering your idea, I may suggest implementing an additional
[Exact Tuning Hz] section while keeping the [Exact Tuning] section for
downwards compatibility.
- Then - relevant for the editor software - I will add a parameter
which tells the software, in which section the original data is placed
to prevent the summing up of conversion inaccuracies when a scale is
loaded and saved several times.

Nowadays, there are scale editors which have many complex
capabilities. I don't want the developers of each music software to
implement these. Keep the complex things once in the place where
needed. And for the "overall use" keep it as simple as possible.

BTW: Forget the idea of creating a capable-of-all format. You do it
today and tomorrow someone else comes with a new special idea your
format is not capable of representing in an optimized way.
Maybe he asks to not store the values but the
parametrized equation/algorithm of how they are generated. And
suddenly you come up with implementing a scripting language in your
format. A week later someone asks for implementing the brain interface
which automatically maps his scale algorithm to his current mood. ;-)

Too much complexity kills.

Just my 2 cents.

Mark

Thank you, Mark. I'm glad to hear that you will be working on updating
the .tun format and please send me a note when you want to begin
discussions on whatever forum is appropriate. I think you're right that
TL may not be the right place, but maybe posting here some summary
notices at various stages to get feedback from fellow microtuners would
be a good idea.

At any rate, I will put together my own idea of an XML format and maybe
even though you are staying away from XML, maybe you (and I hope
Manuel) can give me feedback and something may also come of that.

Anyone with any relevant ideas, please send me email as well. Unless
anyone wants to post further of course, I guess at this point discussion
on TL for this topic might close.

Thanks!
Aaron Hunt
=====

--- In tuning@yahoogroups.com, "Mark Henning" <maillists8377@...> wrote:
>
> --- In tuning@yahoogroups.com, "Aaron Krister Johnson" <aaron@> wrote:
> > The only problem is the age-old 'legacy problem',
> > where as un-ideal as older solutions are, most
> > existing software now uses them!
>
> Full ACK. Any new format will fail if there is no software which
> supports it.
>
> Besides that, someone in this thread mentioned, writing a XML parser
> would be thus easy. O.K., then do it. I'm not in the details of XML.
> I'm sure that I could create some format description which would look
> similar to XML, but I don't know the standards of XML to ensure that
> it _is_ a valid XML file.
>
> That's why I keep my hands away from XML in general.
>
> And: If you wrote a XML parser, take the source an compare it with
> e.g. my sources of the .tun format. I assume, that the XML source would be
> a) overwhelming in size
> b) rather complicated which may prevent developers from using it (keep
> in mind that they may have to port it to another programming language!)
>
> That's why I expect problems when creating a complex format.
>
> But nevertheless, I agree that the .tun standard could have some
> improvements. But downwards compatibility will be the main task to
> make the developers and users accepting it.
>
> Furthermore, this Yahoo group is not the right place for these
> discussions, as there are too few developers presented. But they
> should, as they have to implement it in their code and they have to
> understand *why* they should implement it.
>
> I think, a better place for this discussion is the kvraudio site, as
> there are lot of users and developers.
>
> When revising the .tun specifications I will post there some
> suggestions for a version 2 (I can drop a note here, if you wish).
> Things I would include is:
>
> - Definition of middle key
> - Parameters for side information as e.g. scale name, creator,
> software used, additional informations/comments
> - I will also discuss the further need of the [Tuning] section. Maybe
> this downward compatibility is no longer needed and can be dropped.
> - Considering your idea, I may suggest implementing an additional
> [Exact Tuning Hz] section while keeping the [Exact Tuning] section for
> downwards compatibility.
> - Then - relevant for the editor software - I will add a parameter
> which tells the software, in which section the original data is placed
> to prevent the summing up of conversion inaccuracies when a scale is
> loaded and saved several times.
>
> Nowadays, there are scale editors which have many complex
> capabilities. I don't want the developers of each music software to
> implement these. Keep the complex things once in the place where
> needed. And for the "overall use" keep it as simple as possible.
>
> BTW: Forget the idea of creating a capable-of-all format. You do it
> today and tomorrow someone else comes with a new special idea your
> format is not capable of representing in an optimized way.
> Maybe he asks to not store the values but the
> parametrized equation/algorithm of how they are generated. And
> suddenly you come up with implementing a scripting language in your
> format. A week later someone asks for implementing the brain interface
> which automatically maps his scale algorithm to his current mood. ;-)
>
> Too much complexity kills.
>
>
> Just my 2 cents.
>
>
> Mark
>

[ Attachment content not displayed ]