パッケージと相互依存構造

• 出版物はブリットに依存〈depend〉する。
• 出版物はブリットに寄与〈contribute〉する。

依存の記述は：

• package.json の dependencies に依存するパッケージとバージョンを列挙する。
• import.json で import from into を列挙する。
• 記事〈.mdファイル〉のメタデータ部〈フロントマター〉に import 宣言を書いてもよい。

インポート

import:
  - 
    terms: [foo, bar, baz]
    from: otherPackage
    citekeys: [a1, b5]
  -
    types: [a, b]
    from: anotherPackage

{
    "import": [
        {
            "terms": [
                "foo",
                "bar",
                "baz"
            ],
            "from": "otherPackage",
            "citekeys": [
                "a1",
                "b5"
            ]
        },
        {
            "types": [
                "a",
                "b"
            ],
            "from": "anotherPackage"
        }
    ]
}

値の集合のあいだの次の制約がある。

$(import.json).import.*.from ⊆ keys($(package.json).dependencies)

• ワイルドカード付きのパス式の意味はよく考えないといけない。
• import.json の import は要らないな。

エクスポート

./export/ に様々なファイルを置く。

• ターム空間、フレーズ・ターム空間〈phrased term space〉
• 引用キー空間
• タグ空間
• その他

再エクスポート

インポートしたトークンをそのままエクスポートしてもよい。これにより、集約パッケージが可能となる。集約パッケージは、複数の名前空間の下で定義されたトークンをひとつの名前空間内に集約してエクスポートする。

他に、文献一覧パッケージ、用語集パッケージ、タグパッケージなどの特定目的のパッケージを作れる。

スケルトンパッケージ、デリバラブルパッケージ

import.json と export/ で構成されたパッケージを[+スケルトンパッケージ]と呼ぶ。内容を公開したくない場合や純集約パッケージはスケルトンパッケージになる。

deliv/ が空でないパッケージをデリバラブルパッケージと呼ぶ。ビルドが自動的でコンテンツが存在するなら、デリバラブルを入れる必要はない。