タグ別アーカイブ: XML

DITA-OTでソースコードを書くならcoderefが便利

DITAでソースコードを書くときはcodeblock要素を使います。

(HTML5では引用ブロックやcodeblock(pre/code)もfigureの子孫として記述する方法がよく見られます。個人的な感覚として、英語だとキャプションに「figure 1」のようにしてソースコードが記載されていても違和感はないのですが、日本語で「図1」となっているところにソースコードが記載されていると違和感があります。)

さて、codeblockの中をどう書くかについて、方針はおおむね次の2つです。

  • 直接書く。XMLの<や>は
    • &lt;のようにして書く
    • xml-mentionドメインのタグを使って書く
  • coderefを使う

今回は記事タイトルにもあるように、coderefを使う方法が便利という話です。

DITA-OTではcodeblockでの処理について、仕様から拡張しています。記事タイトルが「DITAでcodeblockを書くときは~」ではないのはDITAの仕様ではないからです。なお、記事を作成する際に試行した環境はDITA-OT 3.7.1となります。

Extended codeblock processing DITA-OT

拡張内容は幾つかあるのですが、先に述べた通り、今回紹介するのはcoderefについてです。

codeblockにはテキストをそのまま記述することもできますが、XMLタグ、というか<などがきっちり処理されてしまうため、XMLやHTMLをソースコードとして例示するのは結構大変です。そこでcoderefです。

coderefは外部ソースコードを(主にテキストとして)参照し、結果を展開してほしい場合に使うタグです。@hrefで参照する先を指定します。XMLを参照する場合、@format=”xml”を付けましょう。

coderefの第一の利点は<をエスケープしなくて済む点です。これについてはDITA仕様のうちです。

coderefを使ったコードブロック
<codeblock xml:space="preserve"><coderef href="hoge.xml" /></codeblock>

ただ、実際のXMLファイルというのは結構行数が嵩みます。「coderefで参照する用にコード片を別ファイルに保存して……」というのはメインテナンス性からするとあまり歓迎できません。そこでDITA-OTの機能によって行数を制限します。

coderefの拡張記法は#から続くフラグメントによるものです。これに対応していない、DITA-OT以外のDITA処理系で使われても、ファイルの全行が出力されるだけで済みます。……結構大変なので、keyrefで切り出して切り換え可能にしておくのが良いかもしれませんね。

行数の記法はドキュメントにある通り、#line-range(<start>,<stop>)またはRFC 5147の記法で#line=<start><end>のようにして開始行、終了行を指定します。

このままで十分便利ですが、「元のソースコードを弄ったらトピックファイルで指定している行位置も変更しなくてはいけないのだろうか」と疑問を持たれたことでしょう。それはあまりメインテナンス性が良くありませんね。ということで、任意文字列を行位置の識別子にする方法が提供されています。
#token=<start-text>,<end-text>を指定すると、ソースコード中のstart-textがある行の次行からend-textがある行の前行までが範囲として取り出されます。想定としてはコメントアウトした行にstart-text、end-textを書いておく形のようなので、あまりトリッキーなことはしない方が良いでしょう。ほかにも幾つかの機能がDITA-OTのページで紹介されていますが、プラグインや処理系依存の機能もあるようなので都度確かめて使うと良いでしょう。

coderefのstart,end用文字列を追加したXML
<!-- example1start -->
<fo:block><fo:inline>Title</fo:inline></fo:block>
!-- example1end -->

ほか、coderefというcodeblockの中で更に別のタグを使うことのメリットは、@hrefで参照した箇所と、直接書く箇所をcodeblockの中で行える点です。

coderefを使ったコードブロック

<codeblock xml:space="preserve"><coderef href="hoge.xml#line-range(1,5)" />
... <!-- 直接書いた部分 -->
<coderef href="hoge.xml#line-range(10,15)" /></codeblock>

1-5行目、「…」を書いて10-15行目、なんて表示も可能になります。

そんなcoderef、DITA 2.0で若干の変更が入ることが現在のドラフトで言及されています。といってもエンドユーザがトピックを記述する上ではそう変化はなく、主に仕様上の立ち位置がより整理されるということのようです。




瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

【動画公開】「DITAで本を書いてAH XSL Formatterで自動組版する」、FormatterClub2021ウェビナーのお知らせ

2021年8月10日に開催しました、ちょっと一息アンテナハウスウェビナー「DITAで本を書いてAH XSL Formatterで自動組版する」の録画を編集した動画が公開されています。

動画は1本10分程度の4本立てとなりました。

ご好評いただけましたようで、当日は予定時間をはみ出すくらいにご質問をいただきました。
「タグを気にせず書きたい」といった意見もございました。個人的には「タグを気にしながら書きたい」派でしたのでそういった方のための資料はあまり用意できていなかったのですが、そういった方面のアプローチも存在しますので、機会があればあらためてまとめたいと思います。

さて、この動画自体は少し前に公開されたのですが、何故今ブログ記事にしているかというと、次のイベントに関連するためです。

FormatterClub2021ウェビナー開催

日時
2021年9月17日(金)17:00~18:10
概要
今回のFormatterClubでは、キヤノンの吉田一様にFormatterでのマニュアル作成と自動組版の取り組みの発表の他、XSL拡張仕様のご説明、AH Formatterの今後をご紹介を致します。
内容紹介・お申込みページ
ウェビナー登録ページ【終了しました】

Formatter Club は、アンテナハウスの XML 自動組版ソフト『AH Formatter』を導入されているユーザーや関心を持っていただいている皆様と開発者とを繋ぎ、会員同士の交流、情報交換により『AH Formatter』の利用技術を向上させ、より皆様のお役に立てる製品としていくために役立てることを目的として発足いたしました。
『AH Formatter』とその関連技術(XSL、CSS、XML 多言語組版など)に関心のある方でしたらどなたも参加できます。参加費は無料です。
Formatter Club の活動には会員メーリングリストを情報交換のために利用し、会員専用の Web ページも提供いたします。また定例会を開催し、会員相互の親睦をはかります。定例会は、『AH Formatter』開発者から最新バージョンの紹介・デモ、活用事例紹介、組版技術の向上のための勉強会などを行います。

Formatter Club について | アンテナハウス株式会社

ということで、「XSL拡張仕様のご説明」として『使いこなしガイド』の紹介をさせていただく予定です。
今回のウェビナーはFormatter Club会員様以外でも参加が可能ですのでお気軽にご登録、ご視聴ください。

関連記事





HTML on Word
WebページをWordで作る!


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

XSL-FO試行錯誤 変換後を意識しながら独自XMLを考える

業務ではなくプライベートの話となるのですが、自分用のXML規格を考えたり、そのXMLを変換するXSLTを書いたりということをしています。

自分用のXMLはさらに自分用の軽量マークアップからの変換によって得ることを想定しているので、スキーマまで作りこもうと日々ジリジリと進めています。

XSLTは組版用でないXMLを組版用のXSL-FOに変換できるわけですが、「軽量マークアップとして書きやすく、XSL-FOやHTMLにもしやすい」XMLというのはなかなか難しいなと感じています。

脚注はDITAではfnタグでマークアップします。XSL-FOではfootnote、footnote-bodyに変換されるでしょう。CSS Paged mediaではspanにした後フロートさせることが多いようです。
Webページ、HTML5的には脚注文の位置はasideの中あたりが良いのでしょうか?ただ、HTMLページの一番下(フッタ)に置いてしまうとPDFや紙でのソレよりも遥か下に行ってしまい、後注、しかもappendix的な配置になってしまうかもしれません。
では脚注用のfootnoteタグを用意するのではなくnoteタグを用意してレイアウトは属性にしましょうか?

変換先がXSL-FOであれば出力は1ファイルが望ましいでしょう。
しかしたとえばDITAなら?元の独自XMLはマップやトピックをどのように扱っていると好ましいでしょうか?独自XML自体が外部ファイルをどう扱うかも重要です。XIncludeなどを援用する、しない。うーむ。

メインの構造をまたぐ構造、たとえば複数段落に対する注釈などについてはrange-startとrange-endのようなタグを作る方式である程度しのげますが、変換後に納得できる構造にできるかは悩ましいところ。

そんなことを考えていると休日が過ぎています。
XMLアプリケーションはそれぞれがそれぞれの用途のために専門化されているので、中間形式のための独自XML規格というのは実は難しいのかもしれません。

DITAで本を書いてAH XSL Formatterで自動組版する

日時
2021年8月10日(火)16:00~17:00
概要
2021年5月18日に公開/販売した『AH XSL Formatter 拡張仕様使いこなしガイド』の制作報告を通し、XML執筆からPDFを作る過程の知見をご紹介します。
DITAについてや、DITAでの書籍制作における実例の紹介や、DITAを扱うときの注意事項など、自動組版やXMLの使い方、DITAに興味がある方、Formatterユーザーさん、必見です!
内容紹介・お申込みページ
こくちーずプロからお申し込み:https://www.kokuchpro.com/event/20210810/終了しました
Zoomウェビナーへ直接お申込みいただく場合: ウェビナー登録ページ終了しました




アウトライナー
PDFを解析して しおり・目次を自動生成


HTML on Word
WebページをWordで作る!

fo:bookmarkというマークアップから考えるしおり

『岩波国語辞典第八版』*1によれば、「しおり(しをり)」には2つの意味があります。

1. 本の読みかけのところに挟んで目印とするもの 2. 初めての人などにわかりよく説明した本。手引き

岩波国語辞典第八版

「目次」は次のように記されています。

(書物の)内容の題目を、書かれている順に並べて記したもの

岩波国語辞典第八版

しおりについて、1の意味では、読み手側が設定するものという印象が強いですね。ちなみに岩波国語辞典だとブックマークはWebブラウザのブックマーク(お気に入り)機能についての言及となっています。

さて、XML組版の仕様であるXSL1.1仕様にはしおりを作成するための機能fo:bookmarkfo:bookmark-titlefo:bookmark-treeが存在します。1.1の仕様に1.0との差異が記載されているのですぐにわかりますが、実は1.0のときには存在しなかった機能です*2

『XSL-FOの基礎 第2版』*3にしおりのFOについての解説があります。また、Antenna House XSL Formatterの*4サンプルFOのページ*5からしおりの設定されたPDFを確認できます。

<fo:layout-master-set>
    …略…
  </fo:layout-master-set>
  <fo:bookmark-tree>
    <fo:bookmark internal-destination="MARK001">
      <fo:bookmark-title font-weight="bold">
    目次</fo:bookmark-title>
    </fo:bookmark>
    <fo:bookmark internal-destination="MARK002"
                 starting-state="hide">
      <fo:bookmark-title>第1章</fo:bookmark-title>
      <fo:bookmark internal-destination="MARK003">
        <fo:bookmark-title>1.1</fo:bookmark-title>
      </fo:bookmark>
     ...
     </fo:bookmark-tree>
     ...
    <fo:page-sequence ...>
      <fo:block font-size="2em" font-weight="bold" space-after="5mm" id="MARK001">Bookmark sample-1</fo:block>
        <fo:block font-size="1.5em" font-weight="bold" id="MARK002">Lorem Ipsum</fo:block>
          <fo:block space-before="4mm" margin-left="2em" line-height="1.4">
         <fo:block keep-with-next="always" font-weight="bold" id="MARK003">Lorem ipsum dolor sit amet</fo:block>
            <fo:block>...</fo:block>
        </fo:block>
...
</fo:page-sequence>

ごく簡単に説明すると、fo:rootの子としてしおりのツリーを用意し、その子として、目的のIDやURLなどをプロパティの値に持つしおりfo:bookmarkとしおりの項目名fo:bookmark-titleを記述します。上の例ではfo:blockにそのIDが記述されていますね。ツリー構造ですので、階層も表現できます。

PDFなど、ページドメディアへの出力を意識したマークアップであるXSL-FOの機能として用意されていることから分かる通り、これは文書コンテンツ提供側が用意するしおりです。
XSL-FOは(中間形式にせよ)ページドメディアとしてかなり明示的なマークアップを求めますから「fo:bookmark*」は「この箇所をしおりとする」というはっきりとした意思表示となります。
文書コンテンツ作成者がコンテンツ頒布時に「この部分は読みかけ」というしおりを作ることは稀なことと捉えて良いでしょう。そして、fo:bookmark-titleというマークアップ名から分かる通り、しおりの項目名は長い段落などを記述する箇所でもありません。

目次項目は当然その項の内容を反映しまとめたものになりますから、しおりは多くの場合目次項目と同じ箇所でマークアップされ、対応したPDFビューアーでは「しおりを表示」といった機能でページ表示とは独立して表示できます。
特に数百、数千ページのPDF文書を頻繁に読む機会のある方は頷かれるのではないかと思いますが、紙の文書ではそれこそ「しおり」を挟んで分厚いページの束をまとめてむんずと掴んで目次に戻ったりできますが、PDFビューアー上で毎回目次ページへ戻って目次項目を確認するというのはそこそこ時間がかかります。

個人的には、しおりの重要な点として「ページ外の要素」であることが大きいのではないか、と考えています。目次で「2.3 詳細 200ページ」、文章中に「299ページに詳細」、索引ページに「fo:bookmark…300p」といったページ参照があるのはそれはそれで重要ですが、「本文を読みながら文書(あるいは文書外)の他の箇所への目印へすぐにアクセスできる」機能がしおりといえるのではないでしょうか。そして、XSLでは文書コンテンツ提供側がそれを提供することになります。

ところで、XSL-FOとXSL-FOプロセッサーによる処理ではPDFの作成時にしおりをマークアップすることになるので、すでにPDFとなっているものにしおりを付与することは範囲外です。Antenna House Formatterでは「PDFを画像のように埋め込む」といったことができるので、多少トリッキーな方法で後からしおりを付与することもできなくはありません。しかし専用のソフトウェアがあればもっと分かりやすく、そして効率的にしおりを付与できます。

antenna house webinar pdf bookmark

隔週で火曜に開催している「ちょっと一息 アンテナハウスウェビナー」、11月10日(火)16時からは「そもそも、PDFのしおりとはなにか ~目次と何が違うのか。どう作って活用するか~ 」というテーマでお送りします。この記事を書いているのが担当者でないため、発表内容の詳細はわかりません。しおりってなんなんでしょうね……。この謎を明かすためにも明日のウェビナーは必見です。

参考文献・資料

  1. *1 『岩波国語辞典第八版』(岩波書店, 2019年11月22日第1刷発行, ISBN 978-4-00-080048-8)
  2. *2 https://www.w3.org/TR/xsl11/#change10
  3. *3 https://www.antenna.co.jp/AHF/ahf_publication/data/xsl-fo-v2/201603282131.html『XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様』(アンテナハウス株式会社, 2017年3月, ISBN 978-4-900552-48-7)
  4. *4 Antenna House Formatter
  5. *5 https://www.antenna.co.jp/AHF/ahf_samples/sample-fo.html#pdf




アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成

LwDITAで(途中まで)ドキュメントを書いてみました

これまでに数回Lightweight DITA(LwDITA)に言及したことがありました。LwDITAやDITAについては記事末尾の関連記事、参考資料をご覧ください。ざっくり書くと、リッチな文書フォーマットとその簡略化版です。

最近、社内でドキュメントにLwDITAを試用して執筆しています。これは少し正確ではなく、より正確にお伝えするなら「執筆していた」となります。現在DITA(ただし一部機能しか使用しない)に移行中となります。

そこそこ文量のあるドキュメントに使ってみての利点、欠点について記そうと思います。一部、実装と仕様どちらに対しての言及であるのか不明瞭である点がありますがご容赦ください。

LwDITAでできること

DITAとしての利点と、LwDITAとしての利点があります。DITAとしての利点はおおよそ次のようになります。

  • DITA文書の一部としてDITA-OTで処理可能
  • conref、keyrefが利用できる
  • トピック単位でファイルを分けて管理できる
  • メタデータに索引用のキーワードを集約できる

LwDITAはDITA文書の一部として、通常のDITAと混在して処理が可能です。管理の観点からすると必ずしも良くはありませんが、「最初LwDITAで書いてDITAへ移行していく」今回の私のユースケースや、「既存資産のDITAやXML形式を利用しつつ新規記述のコストを減らす」といったときに有用です。

conrefやkeyrefはDITAの機能で、簡単に言えばプログラム言語における変数をドキュメント中に使用できます。専門語の揺れを防いだり、URLの変更などに対応できます。長期的に同じドキュメントを使用したいときに便利です。

「トピック単位でファイルを分割して管理できる」、DITAがトピック指向の設計であるので、条件が合致するときは各ドキュメントの構成のシンプルさを保つことができます。後述する「索引の半自動化」に係わるところです。「メタデータに索引用のキーワードを集約できる」というのも大体同じメリットですが、メタデータを書く箇所がフォーマット側で各ファイル単位に用意されているものは実はあまり多くありません。

そして1行では書きにくいメリットとして、構造のどの位置で呼ばれたかによって、適用されるセクションレベルを変更できるという恩恵があります。簡単に例を挙げると、h2レベルの内容の途中で呼ばれた別ファイルの見出しトップレベルはh3と解釈されます。書いているうちにトピックを分割したくなったときなどに有用です。

LwDITAとしてDITAに対する利点は次があります。

  •  単純な最低限のマークアップ(em、strong、italic、リスト……)

メディアコンテンツ対応も地味に仕様としてはDITA1.3より進んでいるのですが、これは出た時期によるもので、実用的にはDITAでも対応されているはず。

さて、とくにMDITA(と一部拡張プロファイルとしてHDITA記法)を利用していたのですが、次の利点があります。

  • MDITAではYAMLフロントマターにkeyword、category、author、source、トピックIDを記述可能
  • DITAに限らず別形式へ変換可能という安心感

メタデータは単純なKeyValue、あるいは簡単な入れ子となるようなものが多いため、汎用エディタを使ってXML形式で記述するのは冗長に感じるときがあります。YAMLでとりあえずパパっと書けるのは楽でした。

最終形をPDFと考えたとき、DITAではやりづらくなる箇所もあるかもということで、別形式にしやすい意味ではMarkdownは安心感があります。その分表現力に制約がかかりますが。

「チームメンバーの記述可能なフォーマットの共通スキルがHTMLやMarkdown」といったケースもありうるかもしれません。

LwDITAでできないこと

  • 対応しているDITAメタデータ(prolog)が少ない
  • 対応しているプロパティ、要素が少ない(特にMDITA)
  • 独自拡張のDITAが対応できない

さもありなんといったところで、作業が進むと、簡易形式ゆえにオミットされた機能が使いたくなってきます。上に挙げた理由で、今はDITA化を進行中です。とはいえ、変換後もLwDITAと対応できない要素はあまり使っていません。

とくにMDITAの不満点として、<note> に対応する記法がありません。以前あった記法もなぜかdepricatedになったので、注やtipsなど、荒涼としたドキュメントにおけるポップでおしゃれなアクセントが書けないのです。

XDITAを飛び越えてフルウエイトのDITAに変換すると、<indexterm>、索引語の指定が使えるようになります。keywordとしてYAMLフロントマターに記述していた語へこのマークアップを行うと、トピックの開始位置に索引が自動でつくように設定できます。入れ子にもできるので索引のサブ項目もほとんど労力をかけずに可能です。

「特殊化したDITA」について軽く触れましたが、AH-DITAという拡張ではfo:propプロパティによってXSL-FO語彙によるスタイル付けをダイレクトに行うことができます。また、図表のフロート配置も<floatfig>で、より自由に行えるようになります。

その他細かいところや全体像などについても、そのうち記事にできればと思います。

参考資料・関連記事




瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


アウトライナー
PDFを解析して しおり・目次を自動生成

XProcの紹介

makeが良い、悪い」という話が一部で盛り上がっているのを見ました。
結局ツールなので、「用途に向いていなくても慣れなどを取る」か「学習が必要でも別のものを使う価値が見合う」かといった、状況に合わせた選択が必要になるでしょう。個人的にはファイルの絶対パスをハードコードするのは可能な限り避けてほしいですが。

ビルドツールにも様々な得手不得手があるものですが、XMLに特化したものもあります。そんな導入で、XProcの話題です。

XProc: An XML Pipeline LanguageはXML文書やその他の処理を記述するための言語です*1
W3CのページのAbstractには“Pipelines generally accept zero or more XML documents as input and produce zero or more XML documents as output.”とあります。ステップ処理として記述ができる、ファイル操作についてもある程度はできるなど他にもありますが、XSLTとは目的も書き味も結構違います。

2010年に1.0がW3C仕様として勧告された後、勧告としてはそれが最新の状態がまだ続いています。しかし、2020年8月19日にXProc 3.0の最終ドラフトが上がっており*2、期待が持てるようになってきました。Editor’s Draftは8月31日に更に更新されていますが。ちなみに2.0は諸般の事情で見送られています。

また、XMLPressから2020年4月に『XProc 3.0 Programmer Reference』(Erik Siegel)*3が刊行されています。W3CのXProc仕様のEditorであるNorman Tovey-Walsh氏による推薦文もついていますし、Erik Siegel氏も XProc 3.0 editorial teamのメンバーです。
XProc 3.0についてはドラフト版仕様とこの本を読むのが確実でしょう。

XProc 3.0でのもっとも大きな改良点はXSLT同様にXPath 3.1に対応したことだと思いますが、今回はXProcの雰囲気だけ紹介します。


<!-- 1. Pipeline document: -->
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
  xmlns:xs="http://www.w3.org/2001/XMLSchema" version="3.0">

  <!-- 2. Pipeline port declarations: -->
  <p:input port="source" primary="true" />
  <p:output port="result" primary="true" />
  <!-- 3. Convert document to HTML: -->
  <p:xslt>
    <p:with-input port="stylesheet" href="xsl/basic-conversion.xsl" />
  </p:xslt>
</p:declare-step>

上のコードは『XProc 3.0 Programmers Reference』*3「Getting started with XProc」にある例です。
<p:declare-step>がルート要素です。inputやoutputを省略できる<p:pipeline>も使用できますが、
2行程度では大して労力は変わらないですね。

XMLSchemaのネームスペースが宣言されているのは、XSLT同様asで型を明示できるからです。

書かれた処理を簡単に書けば、「入力をxsl/basic-conversion.xslのXSLTで処理し、出力へ渡す」ということになります。しかし、よくわからないプロパティportの存在がありますね。それぞれの指定で想像が付くかと思いますが、inputによる入力を処理対象(source)というportにつなぎ、with-inputによる入力は(XSLT)スタイルシートというportにつなぎ、このスタイルシートによってsourceを処理します。そしてresultというportにつながった出力へ結果を渡す、という流れです。こう書くと同語反復をしているように感じられるかと思いますが、それぞれのportにきたものをステップ処理していく流れが直観に近い記述で書けるということです。他のportとしては、スキーマの検証のスキーマを渡すためのschemaなどがあります。
<p:xslt><p:validate-with-xml-schema>はデフォルトのstepです。portは決まったstepと結びついていて、portに渡したものは結びついたstepが記述されていれば、そのstepで処理されます。デフォルトのstepとport、そして独自のstepと結びついた独自のportを記述していくことがXProcの基本となります。

*1 https://www.w3.org/TR/xproc/
*2 https://spec.xproc.org/lastcall-2020-08/head/xproc/
*3 https://xmlpress.net/publications/xproc-3-0/





瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


HTML on Word
WebページをWordで作る!

XSLT 3.0(XPath 3.1)JSONをXMLに変換せずに利用する

先週はXMLの形にしたJSONを、XMLにしないまま扱う方法について紹介します。CSLはでてきません。

XPath 3.1*1で名前にJSONが入る関数は4つです。

  • fn:parse-json($json-text as xs:string?, $options as map(*))
  • fn:json-doc($href as xs:string?, $options as map(*))
  • fn:json-to-xml($json-text as xs:string?, $options as map(*))
  • fn:xml-to-json($input as node()?, $options as map(*))

$optionsについては説明しません。JSONをテキストとして引数にとるのがfn:parse-json()fn:json-to-xml()
fn:json-doc()は外部JSONファイルを読み込むときなどに指定します。fn:unparsed-text()で取得したテキストをfn:parse-json()へ適用するのと
大体同じことを行います。今回取り上げるのはfn:parse-json()fn:json-doc()についてです。

mapとarray

関係する名前空間は次に挙げるものです。

  • fn=”http://www.w3.org/2005/xpath-functions”
  • map=”http://www.w3.org/2005/xpath-functions/map”
  • array=”http://www.w3.org/2005/xpath-functions/array”

XPath 3.1のmap構造とarray構造は一般的なプログラミング言語におけるそれとほぼ同じもので、JSONオブジェクトをそのままの形で格納できます。
先週登場したJSONを見てみましょう。

{
    "items": [
        {
            "id": "7646893/2E3MJB9A",
            "type": "book",
            "title": "スタイルシート開発の基礎",
            "publisher": "アンテナハウス株式会社",
            "publisher-place": "Tokyo",
            "event-place": "Tokyo",
            "ISBN": "978-4-900552-23-4",
            "language": "ja",
            "author": [
                {
                    "family": "アンテナハウス株式会社",
                    "given": ""
                }
            ],
            "issued": {
                "date-parts": [
                    [
                        2016,
                        5
                    ]
                ]
            }
        }
    ]
}

このJSONを外部ファイルとして取り込むには次のように記述します。

<xsl:param name="input" >'exported-data.json'</xsl:param>
...
<xsl:variable as="map(*)" name="jsonMap" select="fn:json-doc($input)"/>
<!-- または -->
<xsl:variable as="xs:string" name="json-text" select="fn:unparsed-text($input)"/>
<xsl:variable as="map(*)" name="jsonMap" select="parse-json($json-text)"/>

XMLに変換した先週と、mapやarrayを活用する今回はこの後がまったく異なります。

次の記述で、先頭のtitleを一息で取得します。

<xsl:value-of select="map:get(array:head(map:get($jsonMap, 'items')), 'title')" />

まず、最も外側のmapから、itemsのキーを持つ要素を取得します(map:get($jsonMap, 'items'))。
キーitemsの値はarray型です。このままmap:get()を行おうとしてもできませんから、arrayの先頭を取り出すarray:head()を使用しています。ところで上の記述はパイプ演算子を使えば次のように書けます。

<xsl:value-of select="map:get($jsonMap, 'items') => array:head() => map:get('title')" />

mapのarrayでは、map:find()を利用することで指定したキーの値を配列で得ることもできます。挙動の詳細はXPath 3.1*1かXSLT 3.0*2のページを確認してください。

typeの値が何種類かに決まっていて、その種類を元にif文の判定をしたいのであれば、次のように書けます。

     <xsl:variable as="map(*)" name="item" select="map:get($jsonMap, 'items') => array:head()" />
      <xsl:if test="map:get($item,  'type') =  'book' or 'proceedings'">
      <xsl:value-of select="map:get($item, 'type')" /> <!-- book -->
      </xsl:if>

もちろんXMLの構造に変換しても同じことはできますが、より一般的なプログラミング言語に近い形で扱えています。

mapやarrayとして扱うために、JSONテキストとして記述してパースしたり、select="map{"key":value}"のような書き方をする以外に、<xsl:map><map-entry>を使うことができます。

mapの操作はエントリの追加やキー指定での削除などの他、map:merge()によるmapの統合、map:for-each()によるmap要素単位での関数適用などが可能です。arrayの方はarray:fold-left()array:fold-right()の畳み込み関数や、array:for-each()でarrayの要素ごとに関数適用などなど、XML形式を扱うよりもすっきりした構文で記述が可能な関数が用意されています。

注意しなければならないこととして、mapであるかarrayであるかを間違えるとうまく値を取り出せません。$itemnodeでもないので、直接xml-to-json()は使えません。

仕様やSaxonのドキュメントとにらめっこをしながら紹介してきたXSLT 3.0とXPath 3.1のJSONの扱いですが、誤りなどありましたらご指摘ください。

*1 https://www.w3.org/TR/xpath-31/
*2 https://www.w3.org/TR/xslt-30/


参考資料





瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識

Citation Style Languageの話(2) – 引用データJSONのXML化

前回引用データとスタイルの分離の必要性については述べていたので、CSL自体の歴史を見てみました。

Citation Style Languageの歴史について、
CSLのページ*1によれば、Bruce D’Arcus氏を中心に開発され、初期はZoteroのSimon Kornblith氏
がコントリビュートしていました。近年は Frank G. Bennett, Jr. と Rintze M. Zelleによって開発が主導されています。リンクが張られている2010年9月の外部記事はすでに読めなくなっていて、Blogは1.0のニュースリリース*2からです。

Wikipediaの記事*3にはその前身はBiblioXという取り組みであると記載されているのですが、2020年8月31日現在BiblioXのページは消失しており、辿ることが少し難しいようです。BiblioXの発表は2004年ですので、合わせれば15年以上の歩みとなります。

脱線しますが、URLが失効しあるものの歴史を辿るのが難しいというのは堪えます。Web Archiveなどのプロジェクトにしても、無限、無制限というわけにはいきません。それでも、参照した情報元が分かるよう引用情報を記述することの大事さを噛みしめています。

引用データのJSONをXSLTでXML化する

さて、CSLの引用データを確認してみましょう。Zoteroの出力一覧に「Citation Style Language …」という文字列が見えます。ポチッとな……無事ダウンロードされました。

「export-data.json」が。


{
    "items": [
        {
            "id": "7646893/2E3MJB9A",
            "type": "book",
            "title": "スタイルシート開発の基礎",
            "publisher": "アンテナハウス株式会社",
            "publisher-place": "Tokyo",
            "event-place": "Tokyo",
            "ISBN": "978-4-900552-23-4",
            "language": "ja",
            "author": [
                {
                    "family": "アンテナハウス株式会社",
                    "given": ""
                }
            ],
            "issued": {
                "date-parts": [
                    [
                        2016,
                        5
                    ]
                ]
            }
        }
    ]
}

引用データそのものは文書レイアウトのような複雑な構造を持ちませんし、XML形式である必要はないですからね。とはいえXSLTでこのデータを扱うにはどこかの段階でXMLに変換する必要があります。幸いなことに2020年のXSLTはJSONだって簡単に扱えます。今回はJSONがXSLT3.0で扱えることを示します。

XSLT 3.0 (というよりXPath 3.1)ではmap、arrayという頼もしい機能が用意されていますが、今回は構造に登場するだけです。次のテンプレートでは、外部ファイルであるexport-data.jsonを読み込んでXMLとして表示します。unparsed-text()でテキストファイルとしてJSONを読み込み、読み込んだJSONをjson-to-xml()でXMLにします。


<xsl:param name="input" >export-data.json</xsl:param>     
<xsl:template name="xsl:initial-template">
      <xsl:copy-of select="json-to-xml(unparsed-text($input))"/>
</xsl:template>

結果のXMLを次に示します。

<?xml version="1.0" encoding="UTF-8"?><!--export-data.xml-->
<map xmlns="http://www.w3.org/2005/xpath-functions">
  <array key="items">
    <map>
      <string key="id">7646893/2E3MJB9A</string>
   <string key="type">book</string>
      <string key="title">スタイルシート開発の基礎</string>
      <string key="publisher">アンテナハウス株式会社</string>
      <string key="publisher-place">Tokyo</string>
      <string key="event-place">Tokyo</string>
      <string key="ISBN">978-4-900552-23-4</string>
      <string key="language">ja</string>
      <array key="author">
        <map>
          <string key="family">アンテナハウス株式会社</string>
          <string key="given"/>
        </map>
      </array>
      <map key="issued">
        <array key="date-parts">
          <array>
            <number>2016</number>
            <number>5</number>
          </array>
        </array>
      </map>
    </map>
  </array>
</map>

XML形式で出力せずに扱う方が便利なこともありますが、とりあえず今回のところは得られた引用データのXMLから一部を抜き取ってFOにしてみます。

<xsl:template match="j:string[@key='title']">
    <fo:inline font-family="sans-serif">『<xsl:value-of select="." />』</fo:inline>
</xsl:template>
<xsl:template match="j:map[@key='issued']">
    <xsl:apply-templates select="j:array[@key='date-parts']"/>
</xsl:template>
<xsl:template match="j:array[@key='date-parts']">
<fo:inline><xsl:value-of select="./j:array/j:number[1]" />年</fo:inline>
</xsl:template>
<xsl:template match="j:string[@key !='title']">
</xsl:template>

これをexport-data.xmlに適用します。かなり省略していますが、
export-data.xmlのtitledate-partsから年の値を取り出し、加工して出力できました。

<fo:inline font-family="sans-serif">『スタイルシート開発の基礎』</fo:inline><fo:inline>2016年</fo:inline>

CSLからXSLT、XSL-FOへの完全な変換まで到達予定でしたが、XPath3.1やXSLT3.0の機能を調べだしたら今回の記事に間に合わなくなったため、少し時間を空けて再挑戦したいところです。

*1 https://citationstyles.org/about/
*2 https://citationstyles.org/2010/03/22/citation-style-language-1-0/
*3 https://ja.wikipedia.org/wiki/Citation_Style_Language

関連記事

  1. Citation Style Languageの話(1)



瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成


アウトライナー
PDFを解析して しおり・目次を自動生成

Citation Style Languageの話(1)

個人用途での電子書籍管理は引用管理ソフトウェアであるZotero[1]を利用しています。物理的な文書も登録管理できますが、蔵書量の関係からまだ手をつけていません。休日にちまちまと登録しているのですが、休日の度に本が増えるので終わりはしばらく来なさそうです。
書きもので技術的内容・事実に依拠した内容を扱うにあたっては参考文献が重要になりますが、参考文献の書式は学会や論文誌によって異なっているものです。つまり、書誌情報と書式を分離して管理、利用する仕組みが求められることになります。このうちオープンで普及しているものとしてはBibTeXといったものがあります。どんなものを使おうとおこる問題ではありますが、BibTeXを使うにはBiBTeXの記法やBiBTeXを処理するツールへの習熟が必要です。

さて、Zoteroではさまざまな形式で管理している参考文献リストを、プラグインによってMicrosoft Wordなどにも出力できます。そしてより柔軟にこのリストを扱うフォーマットとしてCitation Style Language(CSL)[2]というXMLに基づくオープンフォーマットが利用できます。
CSLを処理するスタンドアロンのソフトウェア*もありますが、XMLですのでXSLTによる処理も可能です。次のCSLはCSL primer[3]のページから一部抜粋しています。

<?xml version="1.0" encoding="utf-8"?>
<style xmlns="http://purl.org/net/xbiblio/csl" version="1.0" default-locale="en-US">
<!-- Generated with https://github.com/citation-style-language/utilities/tree/master/generate_dependent_styles/data/asm -->
<info>
<title>Applied and Environmental Microbiology</title>
<id>http://www.zotero.org/styles/applied-and-environmental-microbiology</id>
<link href="http://www.zotero.org/styles/applied-and-environmental-microbiology" rel="self"/>
<link href="http://www.zotero.org/styles/american-society-for-microbiology" rel="independent-parent"/>
<link href="http://aem.asm.org/" rel="documentation"/>
<category citation-format="numeric"/>
<category field="biology"/>
<issn>0099-2240</issn>
<eissn>1098-5336</eissn>
<updated>2014-04-30T03:45:36+00:00</updated>
<rights license="http://creativecommons.org/licenses/by-sa/3.0/">This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License</rights>
</info>
</style>

この基本情報と、テキスト中での引用書式、参考文献リストでの引用書式、
ロケールによる表示変更、その他書式のためのマクロといった要素を組み合わせたものがCSLの構造です。
つまり、XSLTを記述する方針は、テキスト中での引用書式cs:citation
参考文献リストでの書式cs:bibliographyの記述を元に出力書式を用意し、そこに情報を流しこんで出力を行うことになります。
cs:macroの内の記述方法などはXSLTと似通ってはいますが、if文でelse節が使えたり、variableやtextの使い方が異なるなど注意を要します。

来週はCSLの経緯の概略と、CSLからXSL-FOへの変換に挑戦予定です。


* CSLを利用できるソフトウェアのリストはCSLのトップページ[2]にあります。

[1] https://www.zotero.org/
[2] https://citationstyles.org/
[3] https://docs.citationstyles.org/en/1.0.1/primer.html

関連記事

Citation Style Languageの話(2) – 引用データJSONのXML化




瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成

海外ウェビナー動画「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(日本語字幕付き)

Xplor International(https://xplor.org/)主催のウェビナーにて、弊社副代表のMichael Millerが発表を行いました。

タイトルは「CSSとXSL-FO:印刷出版に私はどちらを使うべきでしょうか?」(原題:CSS or XSL-FO: Which should I use for producing print publications)です。
「CSSとXSL-FO、どちらを使うべきでしょうか?」という質問をよくいただきます。こののウェビナーではCSSとXSL-FO、それぞれの特徴や歴史的な背景を昨今の出版を取り巻く環境も含めてご紹介しています。技術的な内容は少なめで、どなたでも理解しやすい内容となっています。

ウェビナーの様子はYouTubeでご覧いただくことができますので、ぜひご視聴ください。

なおYouTubeの字幕機能を使えば、日本語字幕付きでご視聴いただくこともできます。
字幕の設定方法は、

  1.  動画右下の設定アイコン(歯車マーク)をクリック
  2. 「字幕」をクリック
  3. 「日本語」にチェックを入れる

以上の設定で日本語字幕付きでご視聴いただけます。



XSL-FO/CSSスタイルシートにより、XMLとHTMLをサーバー上で高速にPDFに変換!



アンテナハウス ウェビナー スケジュール一覧 2020




HTML on Word
WebページをWordで作る!


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!
Pages: 1 2 3 4 5 6 7 8 Next