設計と実装と実現

Web拍手：

Peter Deutsch さんが，ひさしぶりにまともなことを言っている．
（この人，DTD を読めば想像がつくことを質問するときがあるので，私はあんまり好きじゃない）

「Finale を利用する」というのは，おっしゃるとおりで「a certain way」だ．
Finale を採用したことによって成功もしたけれど，失敗もしているような気がする．

すでにある実装から仕様をつめていくと，ある時期にかなりの手戻りを食らってしまう．
設計から実装に進んだときと違って，そのときの手戻りはたいてい莫大な作業量になる．
さらに，手戻りすべき時期に手戻りしないでごまかして進み続けると，本人も周辺も疲弊していってしまって，さらには人が離れていく．
とはいえ，その手戻りを食らう頃に，その仕様や実装がすでに古いものになるようなときは，実装から仕様をつめるというのは，実用面で手っ取り早いこともある．
MusicXML は，最初はそのつもりでいたのかもしれない．

でも，いまになっても MusicXML のデータ構造やこまごました設計を Finale にべったり依存して決めるのは，そろそろデメリットのほうが大きくなっているんじゃないかなぁ．
たとえば， という概念が必要になるのは，Finale がレイヤーという概念を採用してしまっているからに他ならない．
なんて，作曲しながら楽譜を書くのにいらないよねぇ．
そうとういい加減な思考で作曲をしないかぎり．
が MusicXML という楽譜データ形式に存在したほうがよい点って，ひょっとしてあるのかなぁ？

せっかく「仕様のメジャー・バージョンアップをしましょう」，となったのだから，ごっそり直しちゃったほうがいいと思う．
いままでの実装やツールを捨てたほうが，簡単でしょう．
もはや大きな手戻りもないだろうから，気が楽だし．

おそらく，Michael さんは，こきたない のはいった MusicXML を処理するプログラムを書いたことがないのではないかと思う．
以外にも「えぇー？」という仕様がいまでも残っているけれども，まぁ，いいやー．

--

Comments

「
The core issue, though, is that music notation itself is loosely
structured.
」

うっひゃー．そんな答えが返ってくるとは．
なんだか，よくわかってしまったよ(^^;)．

--

Posted by NOIKE at 2007年04月27日 18:43