[OSASK 771] Re: タグシステム(Re: フォーマットについて).

[n-hashi !Atmark! interlink.or.jp]

やっほぉ、<小柳の旦那>
[2000年6月6日(火)]にもろた
【[OSASK 765] Re: タグシステム(Re: フォーマットについて).】への返答っ! 。

小柳>> んー、ではこの「TAG利用しまくりフォーマット」を
小柳>> 中間フォーマット（というか変換用フォーマット）として提供するのはどう？
小柳>> 後々いいフォーマットが出るまでの中継ぎ程度ならこなせるのでは？
小柳>> もちろん高速性を狙って直接変換とかを利用するコンバーターを
小柳>> 使ってもいいので、あくまで汎用（に近い）利用方法のできるフォーマットとして、ね。
小柳>この部分ですが、私のイメージとしては、、
小柳>タグと既存の機能的に有望な画像フォーマットのファイルを合わせて、一つの完
小柳>全な画像を表現するものとしてユーザに見えるようにしたいと思っています。

つまり既存の画像形式に、不足分をTAGで補うような形にする、ってことでしょうか？

小柳>(1)初心者ユーザにはそのファイルが画像であることしか分からない。
小柳>(であって欲しい―ファイルの種類が「画像」とのみ表示されるとか)
小柳>拡張子みたいなものは、存在して欲しくないのです。フォルダを開くと
小柳>サムネイルとタイトルしか見えない状態くらいが理想です。

Shellとしてかなりの部分を覆い隠すこの形にすることは、十分に可能だと思います。
「拡張子」も、要するにシステム側の用いる一種の識別子であるだけなので、
TAGで置き換えることは十分に可能なハズです。

あと結構難しい、ってことになってましたが、異種データ（例えば音声）とかを
映像化するようなコンバーター等で、一方向性のもの（逆保存のコンバーターが
存在していない場合、まあ異種データに限りませんが）の場合に
自動的にReadOnlyのような形にする機能もShellとして提供するべき部分・・・
なんだろうなぁ、きっと(*_*)

小柳>データファイルの種類は、
小柳>・画像
小柳>・動画
小柳>・音楽
小柳>・ドキュメント
小柳>のように日常で人が扱っているデータに最も近い形で分類する。分類数は
小柳>両手で数えられるくらいがいい。

いいですねぇ。実際それくらいにまとめられるでしょうね。
しかし現行ではどれだけのデータ種別があることやら・・・

小柳>また少し外れますが、アプリケーションでファイルを開く時に、
小柳>対象となる拡張子のファイルのみを表示していますが、
小柳>いちいちフォルダの候補に必要ない
小柳>\Windows
小柳>\Program Files
小柳>のようなフォルダまで必ず見えてしまいますよね。これも嫌です。
小柳>画像ファイルを開く時には、画像ファイルがないパスは表示して欲しくないで
小柳>す。

これはファイルダイヤログ関連だと思うのですが、DLLでのユニット化もふくめて
結構詰めた記憶があります。
少なくとも不必要なディレクトリの表示非表示程度なら、それほど手間を
かけずに出来るハズです。（TAGでその属性を作って、ファイルダイヤログを
経由する形でアプリ側から管理することもできるんぢゃないかな、と）
それ以前に、データを収めるような所にそのようなディレクトリへの経路を
作成しなければOKっす。

小柳>普通のツリー構造の場合なら、あるフォルダに画像がある場合は、
小柳>親ディレクトリに「画像」があることを通知していって各フォルダに
小柳>おいてそのフォルダより下位に「画像」が無ければ、画像を扱う
小柳>アプリケーションにはそのフォルダを見せないという仕組があるといいです。
小柳>もちろん、エイリアスやシンボリックリンクやショートカットがあると話は
小柳>複雑になるので、そう簡単にはいかないのですが。

んと、OSASKのディレクトリ構造は、（ツリー構造をエミュレートすることはできますが）
基本的に現行のツリー構造によるものではありません。
細かな点は過去ログ参照してほしいのですが、要するに点在するグループごとに
経路を作っていく代物です。
＃よくわからんが、知り合いがKJ法に似ていると抜かしてました。

小柳>(2)ある「画像」のプロパティでは実際に内部的に用いられている画像
小柳>フォーマットがヘッダに持つ属性とその画像フォーマットでは表現できない
小柳>属性を合わせて、「画像」に必要な(と考え策定している)全ての属性を
小柳>得ることができる。

TAG管理用のデータベースはファイル管理データベースと合わせて頭の痛いところですが
階層構造を使えるとしたらそれほど（？）面倒でも無いかもしれないなぁ、と
思いたい今日このごろ・・・

小柳>(3)アプリケーションがシェルに自分が理解できる画像形式を通知すると、
小柳>あたかもそこには、その画像形式のファイルがあるように見える。

これは問題ないですね。

小柳>(4)しかし(3)は旧来のOSのアプリケーションのファイルの扱い方であって
小柳>OSASKのアプリケーションならその画像(ファイル)を読み込もうとすれば(2)
小柳>の全てを得ることが可能なはず。あるいはシェルがBMPという画像ファイルでは
小柳>なくて（2）の属性を持つ「画像」をアプリケーションに引き渡すことができ
小柳>る。

出来ますね。ファイルダイヤログに渡る段階でコンバートをかけてもいいですし
ファイルの存在のみを求めて（要するに「画像」のTAGのファイルのみを集めて）
選択させるようなことも可能なハズです。
前者はプレビュー表示させるような場合に使うのでしょうし、後者は速度優先の
物でしょう。
＃今思いついたけど、サイズ固定のプレビュー専用のコンバーターもあるとうれしいね。

小柳>(5)タグシステムを他のOSと現在標準的な技術で表現するとすると多分XMLという
小柳>ことになるでしょう。グラフィッカーが、絵を描いてBMP形式で保存して
小柳>(A.BMP)、作者名とかコメントとかをタグ付けしてXMLで保存して(A.XML)
小柳>でOSASKのファイルシステムに取り込むと「画像A」という一つのファイル
小柳>になる(見える)というように他のOSとOSASKのファイルの対応付けができるかと
小柳>思います。

XML関連の端末がどこまで動きだせるかにかかってますね(^^ゞ

でわでわ

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/  氏名：もしかしたら橋　直行                                      _/
_/  E-mail:n-hashi !Atmark! interlink.or.jp,PXW06256 !Atmark! nifty.ne.jp             _/
_/_/_/_/_/_/_/_/_/_/_/_/_/-----平成12年06月06日(火曜日) PM11時53分_/_/