データの種類:

Question 1

コメントで述べたように、この質問はむしろ詳細が不十分です。ただし、メタデータの「テストスイート」のようなものを書くのは比較的簡単です。コマンドなどは\title、\author引数を内部マクロなどに書き込みます\@title。\@authorたとえば、正規表現を使用して、これらの内部マクロの値を検査できます。これは決してこのようなチェックを実行するための最良または最も簡単な方法ではありませんが、概念実証として役立ちます。

ただし、一般的には、これらのフィールドではほとんどの入力が許可されることに注意してください。以下のおもちゃの例では、いくつかのルールを定義しましたが、ルールを破ることが合理的である状況を想像するのはそれぞれにとってかなり簡単です。これは私のおもちゃのルール自体の制限ではないと思います。あなたが思いつく可能性のあるどのルールにも例外があります。

さて、コードです。まず、\addressと同様にを定義します\title(つまり、引数をに格納します\@address)。このコマンドはクラスでデフォルトで定義されていないためですarticle。

次に、チェック中に表示されるいくつかのメッセージを設定します。その後、内部マクロがトークンリストにコピーされ、正規表現の入力として使用されます。

残りのコードは一般的な管理用です。何らかの理由で\regex_matchトークンリストを受け入れません。変数ただし、直接トークンリストのみなので、バリアントを作成する必要があります。パッケージコードとユーザーコマンドを分離し、すべてを 1 つの.styファイルにまとめることにしました。

ファイルmetadatacheck.sty：

\ProvidesPackage{metadatacheck}[2024/01/07 v0.1 Regex Check on Metadata]
\newcommand{\address}[1]{\gdef\@address{#1}}

\ExplSyntaxOn
\prg_generate_conditional_variant:Nnn \regex_match:nn {nV} {T,F,TF}
\msg_new:nnnn{metadatacheck}{titleok}{Title~check~OK}{}
\msg_new:nnnn{metadatacheck}{authorok}{Author~check~OK}{}
\msg_new:nnnn{metadatacheck}{dateok}{Date~check~OK}{}
\msg_new:nnnn{metadatacheck}{addressok}{Address~check~OK}{}

\msg_new:nnnn{metadatacheck}{titleerr}{Title~does~not~start~with~upper~case}{}
\msg_new:nnnn{metadatacheck}{authorerr}{Author~cannot~have~numbers}{}
\msg_new:nnnn{metadatacheck}{dateerr}{Date~does~not~include~4-digit~year}{}
\msg_new:nnnn{metadatacheck}{addresserr}{Address~too~short~(5~characters~minimum)}{}

\cs_new:Nn \check_meta_data: {
\tl_set:Nx \l_title_tl {\@title}
\tl_set:Nx \l_author_tl {\@author}
\tl_set:Nx \l_date_tl {\@date}
\tl_set:Nx \l_address_tl {\@address}

\regex_match:nVTF{\A[A-Z]}{\l_title_tl}{\msg_note:nn{metadatacheck}{titleok}}{\msg_warning:nn{metadatacheck}{titleerr}}
\regex_match:nVTF{\A[^0-9]+\Z}{\l_author_tl}{\msg_note:nn{metadatacheck}{authorok}}{\msg_warning:nn{metadatacheck}{authorerr}}
\regex_match:nVTF{\d{4}}{\l_date_tl}{\msg_note:nn{metadatacheck}{dateok}}{\msg_warning:nn{metadatacheck}{dateerr}}
\regex_match:nVTF{.{5}}{\l_address_tl}{\msg_note:nn{metadatacheck}{addressok}}{\msg_warning:nn{metadatacheck}{addresserr}}
}
\NewDocumentCommand{\CheckMetaData}{ }
{
\check_meta_data:
}
\ExplSyntaxOff

ユーザードキュメント:

\documentclass{article}
\usepackage{metadatacheck}
\title{my Title}
\author{Alic3 Sm1th}
\date{Christmas '23}
\address{23 Mulholland Drive}
\CheckMetaData

\begin{document}
\maketitle
\end{document}

結果（ターミナルとログファイル内）:

Package metadatacheck Warning: Title does not start with upper case

Package metadatacheck Warning: Author cannot have numbers

Package metadatacheck Warning: Date does not include 4-digit year

Package metadatacheck Info: Address check OK

もちろん、ドキュメントコマンドまたは構成ファイルを使用して、ユーザーが正規表現とメッセージを提供できるようにすることで、これをさらに拡張することもできます。

Answer

コメントで述べたように、この質問はむしろ詳細が不十分です。ただし、メタデータの「テストスイート」のようなものを書くのは比較的簡単です。コマンドなどは\title、\author引数を内部マクロなどに書き込みます\@title。\@authorたとえば、正規表現を使用して、これらの内部マクロの値を検査できます。これは決してこのようなチェックを実行するための最良または最も簡単な方法ではありませんが、概念実証として役立ちます。

ただし、一般的には、これらのフィールドではほとんどの入力が許可されることに注意してください。以下のおもちゃの例では、いくつかのルールを定義しましたが、ルールを破ることが合理的である状況を想像するのはそれぞれにとってかなり簡単です。これは私のおもちゃのルール自体の制限ではないと思います。あなたが思いつく可能性のあるどのルールにも例外があります。

さて、コードです。まず、\addressと同様にを定義します\title(つまり、引数をに格納します\@address)。このコマンドはクラスでデフォルトで定義されていないためですarticle。

次に、チェック中に表示されるいくつかのメッセージを設定します。その後、内部マクロがトークンリストにコピーされ、正規表現の入力として使用されます。

残りのコードは一般的な管理用です。何らかの理由で\regex_matchトークンリストを受け入れません。変数ただし、直接トークンリストのみなので、バリアントを作成する必要があります。パッケージコードとユーザーコマンドを分離し、すべてを 1 つの.styファイルにまとめることにしました。

ファイルmetadatacheck.sty：

\ProvidesPackage{metadatacheck}[2024/01/07 v0.1 Regex Check on Metadata]
\newcommand{\address}[1]{\gdef\@address{#1}}

\ExplSyntaxOn
\prg_generate_conditional_variant:Nnn \regex_match:nn {nV} {T,F,TF}
\msg_new:nnnn{metadatacheck}{titleok}{Title~check~OK}{}
\msg_new:nnnn{metadatacheck}{authorok}{Author~check~OK}{}
\msg_new:nnnn{metadatacheck}{dateok}{Date~check~OK}{}
\msg_new:nnnn{metadatacheck}{addressok}{Address~check~OK}{}

\msg_new:nnnn{metadatacheck}{titleerr}{Title~does~not~start~with~upper~case}{}
\msg_new:nnnn{metadatacheck}{authorerr}{Author~cannot~have~numbers}{}
\msg_new:nnnn{metadatacheck}{dateerr}{Date~does~not~include~4-digit~year}{}
\msg_new:nnnn{metadatacheck}{addresserr}{Address~too~short~(5~characters~minimum)}{}

\cs_new:Nn \check_meta_data: {
\tl_set:Nx \l_title_tl {\@title}
\tl_set:Nx \l_author_tl {\@author}
\tl_set:Nx \l_date_tl {\@date}
\tl_set:Nx \l_address_tl {\@address}

\regex_match:nVTF{\A[A-Z]}{\l_title_tl}{\msg_note:nn{metadatacheck}{titleok}}{\msg_warning:nn{metadatacheck}{titleerr}}
\regex_match:nVTF{\A[^0-9]+\Z}{\l_author_tl}{\msg_note:nn{metadatacheck}{authorok}}{\msg_warning:nn{metadatacheck}{authorerr}}
\regex_match:nVTF{\d{4}}{\l_date_tl}{\msg_note:nn{metadatacheck}{dateok}}{\msg_warning:nn{metadatacheck}{dateerr}}
\regex_match:nVTF{.{5}}{\l_address_tl}{\msg_note:nn{metadatacheck}{addressok}}{\msg_warning:nn{metadatacheck}{addresserr}}
}
\NewDocumentCommand{\CheckMetaData}{ }
{
\check_meta_data:
}
\ExplSyntaxOff

ユーザードキュメント:

\documentclass{article}
\usepackage{metadatacheck}
\title{my Title}
\author{Alic3 Sm1th}
\date{Christmas '23}
\address{23 Mulholland Drive}
\CheckMetaData

\begin{document}
\maketitle
\end{document}

結果（ターミナルとログファイル内）:

Package metadatacheck Warning: Title does not start with upper case

Package metadatacheck Warning: Author cannot have numbers

Package metadatacheck Warning: Date does not include 4-digit year

Package metadatacheck Info: Address check OK

もちろん、ドキュメントコマンドまたは構成ファイルを使用して、ユーザーが正規表現とメッセージを提供できるようにすることで、これをさらに拡張することもできます。

Question 2

現在、スコット・パキンが開発したctanで利用可能なパッケージが少なくとも1つあります。https://ctan.org/pkg/hyperxmp?lang=en ハイパーXMPOP が要求していることを実行でき、拡張する必要がある場合は良い出発点になります。

コメントでは、開発作業を行う前にまず仕様を記述することが提案されました。私は Adobe の仕様へのリンクも提供しましたが、これは良い例だと思います。多くの場合、列挙されたリストとテーブルのみを使用できます。私の意見では、最も重要な部分はプログラムの範囲です。質問のコンテキストでは、メタデータが異なるプログラム間で情報を交換するためのインターフェイスであることを考えると、どのソフトウェアがこの情報を読み取ることが期待されるかに答える必要があります。仕様が記述されると、検証機能を開発できます。必要に応じて、さまざまな書き込みシステムとエンコードをカバーするように注意する必要があります。

LaTeX パッケージの要件に準拠した日付のデータ検証の例は、l3 プログラミングレイヤーを使用して記述された l3doc リストにあります。これは、l3 プログラミングの驚異的な技です。

注意点としては、Web 開発も同様の開発段階を経てきましたが、検索が改善され、LLM の登場により、このようなオントロジーは完全に消滅する可能性があるため、実際には普及しませんでした。ただし、これは単なる私の意見であり、皆さんを落胆させる意図はありません。

Answer

現在、スコット・パキンが開発したctanで利用可能なパッケージが少なくとも1つあります。https://ctan.org/pkg/hyperxmp?lang=en ハイパーXMPOP が要求していることを実行でき、拡張する必要がある場合は良い出発点になります。

コメントでは、開発作業を行う前にまず仕様を記述することが提案されました。私は Adobe の仕様へのリンクも提供しましたが、これは良い例だと思います。多くの場合、列挙されたリストとテーブルのみを使用できます。私の意見では、最も重要な部分はプログラムの範囲です。質問のコンテキストでは、メタデータが異なるプログラム間で情報を交換するためのインターフェイスであることを考えると、どのソフトウェアがこの情報を読み取ることが期待されるかに答える必要があります。仕様が記述されると、検証機能を開発できます。必要に応じて、さまざまな書き込みシステムとエンコードをカバーするように注意する必要があります。

LaTeX パッケージの要件に準拠した日付のデータ検証の例は、l3 プログラミングレイヤーを使用して記述された l3doc リストにあります。これは、l3 プログラミングの驚異的な技です。

注意点としては、Web 開発も同様の開発段階を経てきましたが、検索が改善され、LLM の登場により、このようなオントロジーは完全に消滅する可能性があるため、実際には普及しませんでした。ただし、これは単なる私の意見であり、皆さんを落胆させる意図はありません。

Question 3

これは正確には回答ではありませんが、上記のコメントで Ulrike Fischer が尋ねた仕様です。まだ初期段階なので、適宜編集します。

パッケージメタデータは、メタデータエントリの使用と検証を定義し、許可します。

新しいエントリを定義するには、次を使用します。

\definemetadataentry[type=
                     format=yyyy-mm-dd,
                     lower_range=0001-01-01,
                     upper_range=9999-12-31,
                     finite_range=,
                     default_value=,
                     optional/required,
                     validation_routine=,
                     hierarchy=
                    ]{name_of_metadata_entry}

どこ：

データの種類:

可能:

数値（整数または小数）
文字列
日付時刻

フォーマット：

定義したデータ型の形式を指定します。

下限範囲=0001-01-01:

上限範囲=9999-12-31:

連続しているか、長すぎて完全にリストできないデータの下限と上限の範囲を定義します。

日付セットの範囲の例: 0001-01-01 から 9999-12-31

有限範囲:

簡単に完全にリストできるデータの範囲を定義します。

デフォルト値:

定義されていない場合にメタデータエントリがデフォルトとする値。

オプション/必須:

特定のメタデータエントリが、それを定義する領域内で必須かオプションかを定義します。

validation_routine (外部):

エントリを検証する外部ルーチンの呼び出し。

階層：

以前に定義された別のメタデータエントリに基づいて再帰的に定義された要素。

定義と使用例