パッケージ内のコンテンツファイルの指定

[ksato9700]

aozora.jsonでパッケージ内にあるファイルを指定する方法を決めたいです。package.jsonのfilesフィールドに相当するものと考えればよいでしょうか。

おそらく取り扱わなければならないバリエーションとして、例えば以下があると考えています。

• 青空形式のテキストがひとつだけの場合
• 青空形式のテキストが複数ある場合
• 挿絵も含む場合
• 青空形式ではない別の形式で記述されている場合 (e.g. html, markdown)

これを例えば

files: [
    {"name": "chapter1.txt", "type": "rubytext"},
    {"name": "chapter2.txt", "type": "rubytext"}
   ...
]

とするのか、あるいは typeは中身から容易に推測できるので不要とか。Typeがあると逆にチェックが必要になり、中身と指定が整合していなかった時にどうするのか決めなければならず、難しいかも知れません。

いかがでしょう？

[takahashim]

基本的には「青空形式のテキストが複数ある場合」というのは想定しないで良いはずです。同じ作品が複数登録されている例もありますが、それらには別の作品IDが振られています。

あと、青空文庫形式のテキストを含まないパターン、というのは、主に著作権が存続しているものについて多数存在しているようです。この場合はリンクになっていて、ファイルそのものを青空文庫は管理しないようになっているようです。

• http://www.aozora.gr.jp/cards/000200/card1015.html
• http://www.aozora.gr.jp/cards/000097/card536.html

[ksato9700]

@takahashim コメント有難うございます。わかり難くて申し訳なかったのですが、制作の途中や校正が完了した段階では複数のファイルに分かれている可能性もあるかと思いました。作業を楽にするためにチャプターごとに分けていたりとか。それをサブミッションしてひとつのファイルにconcatしてリリースできる形にするのが pubserverの一つの役割と考えています。

[cognitom]

手元で、自動的にconcatさせるなら、ひとまずは1ファイルの想定でも大丈夫でしょうか?

たとえば、次みたいなファイル構成で、main.txt に結合されるなら、これだけ見ておけば良さそう。

+ aozora.json
+ main.txt
+ src
  + chap1.txt
  + chap2.txt
  + footer.txt

思いつきですが、こんなのがaozora.jsonに書けるとか...

"script": {
  "prepublish": "cat srt/*.txt >> main.txt"
}

[ksato9700]

やはり、次はScriptの拡張に行きますよね ;-)

そこも議論のポイントかと思いますが、prepublishはクライアント側で実行のイメージですかね。それともサーバ側にアップロードした後に実行ですか？　前者だとクライアント側にある程度のツールがある前提を置く必要がありそうです。

上記の例だと

+ aozora.json
+ src
  + chap1.txt
  + chap2.txt
  + footer.txt

というパッケージをuploadし、scriptをサーバ側で実行してmain.txtをつくる感じですかね。

とすると、こんな指定も欲しくなるかも。

"script": {
  "prepublish": "cat src/*.txt > main.txt"
},
"main": "main.txt"

scriptは書けると強力なのですが、セキュリティを考えるとちょっと日和る部分もあります。やるのがconcatくらいだったら、arrayでファイルを指定しておいてそれらをその順にconcatするくらいでも良いのかなと思った次第で。

[cognitom]

クライアント側で実行のイメージ

でした。中央の仕様をなるべく軽くしたい気はするんですよね〜。catコマンドって、Windowsだとないんでしたっけ... (汗)

[cognitom]

scriptで、各種校正ツールを走らせるのも手です。lint的に。

[ksato9700]

そうですね。そこはクライアント側ツールの機能との兼ね合いにもなると思います。個人的には、aopm verifyみたいなコマンドができるイメージでした。

そしてサーバー側にできるだけ負荷をかけない様にしたいとは思いますが、クライアントが複数できることを考えるとある程度、サーバに寄せておいた方が良いかも知れません。GUIなツールや、各種エディタに組み込んだ形の実装になりますよね。

ま、その場合もaopmを外部コマンドとして呼び出すのであればそこに機能集約するというのはありますが。

あと、受け付けたデータの整合性確認はいずれにしてもサーバ側で必要かと思ってます。

[cognitom]

"Do one thing and do it well"で行きたい派です w
aopm verifyで呼び出せるけれど、実際のプログラムは別リポジトリみたいなのが好きというかキレイだと思うんですがどうでしょうか? 内部でrequireしているとか、aozora.jsonで

"scripts": {
  "verify": "aozora-lint ./"
}

するとかのイメージです。

[takahashim]

ちょっと出遅れましたが、青空文庫のテキスト版はヘッダ・フッタとかが存在する程度には構造化されているので、青空文庫のテキストの断片（フラグメント）とテキスト全体のvalidateする仕組みは異なりそうです。まあ、基本はconcatしてからのvalidationになりそうですが、その場合には元のファイル名と行番号をエラー情報として出力したくなるのは考慮したいところかもです（単純なcatでは問題がありそう）。

また、aozora.jsonに何を求めるかによりますが、「手続き・処理」等の動的な側面を指定するフォーマットと、構造やメタデータ等の静的な側面を指定するフォーマットはだいぶ異なりそうなので、混ぜるな危険な感じはしました（が、例えば工作院での処理に使うJSONとwww.aozora.gr.jp的なサイトでメタデータ配信用のJSONを全く別個に作るのはナンセンスですし、いろいろ混ぜたい要望は避けられないんですよね…）。

[cognitom]

npmの場合、publishした時点で、package.jsonの中身がある程度自動的に変更されます(READMEの埋め込みとか)。aozora.jsonの場合も、手続き的な部分はフィルタして(外して)公開するのはどうでしょう?

その場合には元のファイル名と行番号をエラー情報として出力したくなる

おお、ソースマップ作りますか...? その辺門外漢ですが、楽しそうではありますね。

[ksato9700]

"Do one thing and do it well"で行きたい派です w
aopm verifyで呼び出せるけれど、実際のプログラムは別リポジトリみたいなのが好きというかキレイだと思うんですがどうでしょうか?

賛成です!
Verifyするプログラムは独自に進化するでしょうし、バリエーションができる可能性もあると思います。