JP4161314B2

JP4161314B2 - Ｘｍｌプリンタシステム

Info

Publication number: JP4161314B2
Application number: JP2003553475A
Authority: JP
Inventors: ブルースエヌアレスハウス
Original assignee: ZIH Corp
Current assignee: ZIH Corp
Priority date: 2001-12-17
Filing date: 2002-11-13
Publication date: 2008-10-08
Anticipated expiration: 2022-11-13
Also published as: EP1456790B1; KR20040063000A; EP1456790A4; EP1456790A1; CN1605081A; BR0215034A; EP2282270A3; EP2282270A2; MXPA04005656A; JP2005513627A; NZ533478A; US6540142B1; CN1605081B; US20030136841A1; US6655593B2; EP2282270B1; AU2002352652A1; CA2467789A1; IL161930A0; WO2003052658A1

Description

本発明は、一般に、バーコードラベルを印刷する方法及び装置に関し、特に１つの具体例においては、既存のＺＰＬ（Zebra Programming Language）ベースのフォーマットテンプレートを用いたＸＭＬデータストリームに基づいてバーコードラベルを印刷するＸＭＬ（Extensible Mark-up Language）プリンタに関する。

関連する特許出願の相互参照
この特許出願は、２００２年１月４日に出願された未決定の仮出願であってＸＭＬプリンタテクノロジー（XML Printer Technology）と題する米国特許出願６０／３４５，３８９と、２００１年１２月１７日に出願された未決定の仮出願であって機械可読な規格を有するバーコードラベリングシステム（Bar Code Labeling Systems Having Machine Readable Standards）と題する米国特許出願６０／３４１，４２７と、２００２年７月１７日に出願された未決定の通常出願であってネイティブＸＭＬプリンタ（Native XML Printer）と題する米国特許出願１０／１９７，０１４とからの優先権の利益を要求するものである。仮出願である米国特許出願６０／３４５，３８９及び米国特許出願６０／３４１，４２７は、参照することによってそれら全てがここに組み入れられる。この特許出願は、２００２年７月１７日に出願された一部継続出願であってネイティブＸＭＬプリンタ（Native XML Printer）と題する米国特許出願１０／１９７，０１４である。

著作権に関する言及
この特許文書のこの開示部分は、著作権保護にしたがう資料を含んでいる。著作権の所有者は、それが特許商標庁の特許ファイル又はレコードに現れることから、いかなる者による特許文書又は特許開示のファクシミリ再生に反対しないが、そうでなければ何に関しても全ての著作権を留保する。

バーコードを印刷してデータをバーコードプリンタに対して送信するプリンタシステムが知られている。しかしながら、このようなシステムの多くは、データ符号化について所有者の方法を用いることから、そのような方法を他のバーコードプリンタとともに交換可能に用いることができない。また、既知のデータ符号化方法は、典型的には、人間によっては判読不可能な基データ（the underlying data）を与える。このことは、コンピュータシステムに対して障害を提示しない一方で、基バーコード要素名（the underlying barcode element names）に現れるあるデータを検査し、デバッグし、又は理解することを試みる人間にとって煩わしいかもしれない。その点で、ＸＭＬは、多くのビジネスエンティティによって採用されており、人間が判読可能であるオープンな規格である。ＸＭＬの使用は、非人間判読可能な方法に関連した多くの問題及び落とし穴を回避するかもしれない。

バーコードラベリングは、商業の多くの面において広範囲に用いられる。特に、ある目的地から他の目的地へと送られたパッケージや商品は、特定のバーコードラベルによって船積み人によって識別される。逆に、バーコードラベルを用いることにより、受け取られた商品も識別され、受け取った人の商品目録システムに入力されてもよい。商品の受取人は、しばしば、船積み人によって適用されたバーコードの形式及び内容を規定してもよい。これは、"コンプライアンス・ラベリング（compliance labeling）"と称される。勿論、商品は、バーコードラベリングの利点を利用するために送る必要がない。例えば、在庫管理システムは、設備内又は設備間の様々な品物を追跡してモニタするために、バーコードラベリングを広範囲に使用する。

コンプライアンス・ラベリングは、典型的には、比較的大規模なマーケット力や購買力を有する商品のバイヤによって用いられる。彼らの経済力のために、彼らは、サプライヤやベンダによって彼らに提供される製品に適用されたバーコードラベルの形式及び内容を規定することができるかもしれない。このことは、サプライヤにとっては煩わしいかもしれないが、当該サプライヤは、バイヤと取引することを望むのであれば、ラベリングに関する彼らの要求に応じるに違いない。例えば、ウォルマート社のような大規模な小売り業者は、サプライヤがコンプライアンス・ラベリングの要求に同意することを要求する能力及び購買力を有するのみならず、ラベリングの要求に応じないサプライヤに罰金を科してもよい。

さらに、そのようなバーコードラベリングの要求は、コンプライアンスを要求するエンティティの気まぐれで変化するかもしれない。したがって、サプライヤは、新たなラベリングの要求を実行し、それが全ての仕様を満たしていると保証するために変換済のバーコードをテストしなければならない。これは、比較的非効率的であり、時間を浪費する。それはまた、誤りを被りがちであり、貨幣の罰金に代えてもよい。

必要性は、ラベルのレイアウトを管理する既存のＺＰＬフォーマットテンプレートをさらに使用させる一方で、及び／又は、印刷されるラベルのレイアウトを管理するためにＸＳＬ（Extensible Stylesheet Language）を用いる純粋なＸＭＬフォーマットテンプレートを使用させることにより、エンタープライズ・リソース・プランニング（ＥＲＰ）・システムがＸＭＬにおけるバーコードプリンタシステムに対する送信用のそのデータをフォーマットすることを可能とするために存在する。

斬新であると考えられる本発明の特徴は、添付した特許請求の範囲において詳細とともに設けられる。それらのさらなる目的及び利点とともに本発明は、添付した図面と結合して以下の記述を参照することによって最も理解される。

この記載された説明において、離散的な使用は、接続詞を含むように意図される。定冠詞又は不定冠詞の使用は、濃度（cardinality）を示すようには意図されない。特に、"the"客体若しくは事物又は"an"客体若しくは事物の参照はまた、複数のそのような客体若しくは事物について記述するように意図される。

図１を参照すると、ＸＭＬプリンタシステム１０のハイレベルのハードウェアブロック図の特定の具体例が一般に示される。図１乃至図６の具体例において、システムのネイティブ又はナチュラルな"言語"は、ＸＭＬであり、これにより、プリンタシステム１０は、"ネイティブＸＭＬプリンタ"と称されてもよい。ＸＭＬプリンタシステム１０は、従来から知られているＲＡＭ１４、ＲＯＭ１６、ハードディスク記憶装置１８、キャッシュメモリ２０、及びデータベース記憶装置２２等（さらに"メモリサブシステム"２６と称する。）のような様々なハードウェアコンポーネントを含むコンピュータ又は処理システム１２を含む。コンピュータシステム１２は、コンピュータ、マイクロプロセッサ、ＲＩＳＣ（reduced instruction set computer）プロセッサ、ＣＩＳＣ（complex instruction set computer）プロセッサ、メインフレームコンピュータ、ワークステーション、単一チップコンピュータ、分散型プロセッサ、サーバ、コントローラ、マイクロコントローラ、及び離散ロジックコンピュータ等のような、従来から知られているいかなる適切な処理装置２８を含んでもよい。例えば、処理装置２８は、インテル社製ペンティアム（登録商標）マイクロプロセッサ、ｘ８６コンパチブルマイクロプロセッサ、又はこれらと等価なデバイスであってもよい。

ユーザインターフェース３０は、コンピュータシステム１２に接続されてもよく、ユーザ及び／又はキーボードによって選択可能なスイッチのような様々な入力装置３６を含んでもよい。ユーザインターフェースはまた、ＬＣＤディスプレイ、ＣＲＴ、様々なＬＥＤインジケータ、及び／又は音声出力装置のような、従来から知られている適切な出力装置４０を含んでもよい。

通信インターフェース４２は、コンピュータシステム１２と外部ソースとの間で通信を行うために、コンピュータシステムに作用的に接続されてもよい。通信インターフェース４２は、例えば、イーサネット（登録商標）ネットワーク、イントラネット、又は他の適切なネットワーク４３としてのローカルエリアネットワークであってもよい。通信インターフェース４２はまた、公衆交換電話網（Public Switched Telephone Network；ＰＳＴＮ）４６又はＰＯＴＳ（plain old telephone system）に接続されてもよく、インターネット４４を介して通信を促進してもよい。専用のリモートネットワークが用いられてもよい。従来から知られているいかなる適切な市販の商業上利用可能な通信装置又はネットワークが用いられてもよい。

さらに、コンピュータシステム１２は、プリンタシステム５０に接続される。プリンタシステム５０は、媒体／紙制御システム５２、プリンタドライバ５４、及び印刷ヘッド機構５６を含んでもよい。バーコードラベルを印刷することができるいかなる適切なプリンタが用いられてもよく、様々なドットマトリクス、インクジェット、レーザ、及び／又はサーマルプリンタを含んでもよい。勿論、ドットマトリクスプリンタは、通常、低品質であり、ラベル出力のより接近したモニタリングを要求することになる。プリンタシステム５０は、熱転写プリンタであるのが望ましい。そのような適切なプリンタは、例えば、イリノイ州ヴァーノンヒルズ（Vernon Hills, Illinois）のゼブラ・テクノロジーズ社（Zebra Technologies Corporation）製のものが利用可能であり、モデルＸｉシリーズ・バーコードプリンタ（ＸｉＩＩＩ＋、９０ＸｉＩＩＩ、９６ＸｉＩＩＩ、１４０ＸｉＩＩＩ、１７０ＸｉＩＩＩ、２２０ＸｉＩＩＩ等）、２８００シリーズ・バーコードプリンタ、モデルＺ４Ｍ，Ｚ６Ｍ，１０５ＳＬバーコードプリンタ等を含んでもよい。いかなる適切なバーコードラベルプリンタが用いられてもよい。

典型的には、そのようなプリンタは、図示しない様々なモータ、ラベルカッター、リボンハンドラー、センサ等を含んでもよい。さらに、そのようなプリンタは、図示しないが、様々な制御入力、又は、媒体センサ、印刷ヘッド温度センサ、ヘッドオープンセンサ、リボンセンサ等のような、従来から知られているセンサを含んでもよい。プリンタシステム５０は、コンピュータシステム１２に設けられるプロセッサ２８以外に、１つ以上の追加のプロセッサ６０を含んでもよい。代替として、コンピュータシステム１２におけるプロセッサ２８は、十分に強力である場合には、別個の処理装置の必要なしにプリンタシステム５０の機能を制御して担ってもよい。印刷ヘッドの制御に関するより重要な詳細は、１９９４年１２月１３日に発行され、本発明の所有者によって所有されている"制御されたリボン材料を備えた熱転写プリンタ（Thermal Transfer Printer With Controlled Ribbon Feed）"と題する米国特許第５，３７２，４３９号明細書でみつかるかもしれない。米国特許第５，３７２，４３９号明細書は、その全体を参照することによってここに組み入れられる。

望ましくは、コンピュータシステム１２及びプリンタシステム５０は、共通の囲いに配置されるが、この方法で必ずしも構築される必要はない。例えば、コンピュータシステム１２は、別個の囲いでプリンタシステム５０とは別個に収容されてもよい。

ここで、図１乃至図３を参照すると、図２は、ハイレベルのソフトウェアブロック図の特定の具体例を示す一方で、図３は、ハイレベルのソフトウェアブロック図及びデータフロー図の組み合わせの特定の具体例を示す。以下に記述するソフトウェアは、図１のコンピュータシステム１２のプロセッサ２８によって実行される。その上、プロセッサ２８は、コンピュータシステム１２及びプリンタシステム５０の両方に共通の機能を実行してもよい。１つ以上のプロセッサがあってもよく、それらは協調して機能してもよく、又は別個に機能してもよい。処理又は処理機能が、コンピュータシステムによって若しくはコンピュータシステムで、又はプリンタシステムによって若しくはプリンタシステムで実行されたとしても、それは、この発明の範囲についての本質ではない。

図２及び図３に示すソフトウェアブロックは、"ＸＭＬパーサ"とも称されるＸＭＬ（Extensible Mark-up Language）プロセッサ７０、ＸＳＬＴ（Extensible Stylesheet Language Transformation）プロセッサ７４、ＸＳＬＦＯ（Extensible Stylesheet Language Formatting Object）プロセッサ７８、"ビットマップ／バーコードレンダリングエンジン（bitmap/barcode rendering engine）"とも称されるバーコードレンダリングエンジン８０、及びプリンタドライバ５４（図１）を含む。プリンタドライバ５４は、関連する処理装置の物理的な位置に応じて、コンピュータシステム１２における処理装置又はプリンタシステム５０における処理装置６０（図１）のいずれかにより、その機能が実行される上述したコンポーネントの例であることに着目すべきである。その上、単一の処理装置は、十分に強力である場合には、ＸＭＬプリンタシステム１０についての全ての機能を担ってもよい。

ＸＭＬスキーマリポジトリ８２（スキーマリポジトリ）は、ＸＭＬプロセッサ７０に対する入力を供給してもよく、一方、ＸＳＬＴスタイルシート（stylesheet）リポジトリ８４（スタイルシートリポジトリ）は、ＸＳＬＴプロセッサ７４に対する入力を供給してもよい。また、例えばＸＭＬプロセッサ７０に対してＸＭＬ入力データストリーム９０を送信するウェアハウス管理システムであるエンタープライズ・リソース・プランニング（ＥＲＰ）・システム８８が示される。ＥＲＰシステム８８は、本質的に、バーコードラベルを印刷するリクエストを起こし、印刷されるバーコード及び他の可変ラベルを形成するＸＭＬデータ又は要素フィールドを提供する。そのような可変ラベルフィールドは、例えば、人間が判読可能なテキスト及び／又はラベル上に印刷された文字のうちのいくつか又は全てを含んでもよい。勿論、いかなるエンタープライズコンピュータシステムが用いられてもよく、この発明は、いかなる特定のタイプのエンタープライズコンピュータシステムを備えた使用に制限されない。

ＸＭＬデータを参照する場合には、２つの基本型、すなわち、ＸＭＬ値データ及びＸＭＬ要素名が、ここに参照されるものとする。ＸＭＬ値データは、可変データ、又は"グリーンストリート１１２２"のようなバーコードラベル上に印刷されると望まれるデータであり、それは、例えば送付先に対応するＸＭＬ値データの一部であってもよい。ＸＭＬ要素名は、任意のラベル又は要素名がＸＭＬ値データを表すために選択される場合におけるＸＭＬ言語意味論の一部であり、その使用は、ＸＭＬ言語によって定義される。典型的には、要素名は、かぎ括弧間に現れる（"＜要素名＞"）。

上述したように、既知のバーコードラベルシステムは、所有者のソフトウェア符号化スキームをしばしば用いる。さらに、そのようなスキームは、しばしば誤りを被りがちであり、基値データ（the underlying value data）は、通常、専門外の個人によっては判読不可能である。既知のシステムにおいて、誤りがエンタープライズシステムから送られた基値データに存在する場合、又はデータが消失したかそうでなければ正しくない場合には、バーコードプリンタは、勿論、それを不正確又は役立たなくして、バーコードラベルにおける誤りを生成するものであって実行するように命じられるものを印刷するであろう。

さらに、コンプライアンス・ラベリングに対処する場合には、既知のシステムは、ラベルの形式又は内容がコンプライアンス・ラベルの要求にしたがって変化する場合に、データ符号化における非自明な変更を要求する。その上、バーコードの形式又は内容におけるそのような変更は、誤りに弱く、コンプライアンスを要求するエンティティによって貨幣の罰金に順次導くことができる。取引関係はまた、特にそのような誤りがコンプライアンスを要求する者のビジネスを崩壊させる場合には、バーコードラベリングシステムにおける継続的な問題によって傷つけられるかもしれない。

本ＸＭＬプリンタシステム１０は、オープンフォーマットを利用する。特に、フォーマットの要求及びバーコードラベルの形式は、全てＸＭＬ言語において定義される。さらに、ＸＭＬがよく定義され使用の全てに利用可能であるのみならず、非プログラマは、最小のトレーニングでＸＭＬデータストリーム又はファイル（又はハードコピー）におけるデータ及びコマンドを理解することができる。

図２及び図３に示される様々なＸＭＬソフトウェアブロックは、商業上利用可能である。いくつかの異なる商業上利用可能なＸＭＬプロセッサ７０が交換可能に又は小さな変更をともなって用いられてもよい。例えば、以下の商業上利用可能なＸＭＬプロセッサ７０が用いられてもよい：ＩＢＭ社製の"Ｃ＋＋のためのＸＭＬ（XML for C++）"、マイクロソフト社製の"ＭＳＸＭＬ３"、オラクル社製の"ＣのためのオラクルＸＭＬ開発キット（Oracle XML Developers Kit for C）"、タイのオープンソースソフトウェアセンタ社（Thai Open Source Software Center, Ltd.）製の"Ｅｘｐａｔ"、又はアパッチ・ソフトウェア・ファウンデーション（the Apache Software Foundation）製の"Ｘｅｒｃｅｓ−Ｃ＋＋"。しかしながら、いかなる適切なＸＭＬプロセッサが用いられてもよい。

同様に、いくつかの異なる商業上利用可能なＸＳＬＴプロセッサ７４が交換可能に又は小さな変更をともなって用いられてもよい。例えば、以下のＸＳＬＴプロセッサ７４が用いられてもよい：インフォテリア社（Infoteria Corporation）製の"ｉＸＳＬＴ"、マイクロソフト社製の"ＭＳＸＭＬ３"、及びＧｎｏｍｅ製の"Ｌｉｂｘｓｌｔ"。しかしながら、いかなる適切なＸＳＬＴプロセッサが用いられてもよい。

さらに、いくつかの異なる商業上利用可能なＸＳＬＦＯプロセッサ７８が交換可能に又は小さな変更をともなって用いられてもよい。例えば、以下のＸＳＬＦＯプロセッサ７８が用いられてもよい：レンダーエックス社（RenderX Corporation）製の"ＸＥＰ"、アンテナハウス社（Antenna House Corporation）製の"ＸＳＬフォーマッタ（XSL Formatter）"、及びアパッチ・ソフトウェア・ファウンデーション（the Apache Software Foundation）製の"ＦＯＰ"。しかしながら、いかなる適切なＸＳＬＦＯプロセッサが用いられてもよい。

なお図１乃至図３を参照すると、ＸＭＬプロセッサ７０は、外部ソース８８からＸＭＬ入力データストリーム９０を受信する。例えば、外部ソースは、ウェアハウス管理システムのようなＥＲＰシステム８８であってもよい。ＸＭＬプロセッサ７０は、本質的に、ＸＭＬ入力データストリーム９０を解析して処理し、従来から知られた"ツリー"構造である１組のノードを生成する。図２及び図３に示されるソフトウェア処理ブロックは、それぞれ、それらの必要な機能を実行するために"ツリー"のノード上で作用する。ＥＲＰシステム８８からのＸＭＬ入力データストリーム９０に含まれる基値データは、処理され、データを保持する"ラベル値ノードツリー（label values node tree）"１００に入力される。

以下は、様々なソフトウェアコンポーネントの動作についての簡潔なあらましである。まず、ＸＭＬ入力データストリーム９０が他の要求されたＸＭＬ文書又はファイルの名前及び位置を識別するテキストを含むことに着目すべきである。そのような１つのドキュメントは、"ＸＭＬスキーマ"又は"スキーマ"と称される。スキーマは、基値データを含むＸＭＬ入力データストリームを検証にするために用いられる。検証が成功した場合には、以下に記述されるスタイルシートが適用される。スタイルシートの名前及び位置はまた、ＸＭＬ入力データストリーム９０において指定される。スタイルシートの適用は、当該スタイルシートの指示のもとに基ＸＭＬ要素名（the underlying XML element names）及び／又は基値データを変換するＸＳＬＴプロセッサ７４によって扱われる。続いて、データは、例えば、フォントタイプ、フォントサイズ、及びカラー等にしたがう基値データのフォーマットを含む基値データのフォーマット及び"レイアウト"を扱うＸＳＬＦＯプロセッサ７８によって処理される。続いて、基値データは、変換されてフォーマットされたデータに対応するバーコードラベルのビットマップ９２を生成するビットマップレンダリングエンジン８０によって処理される。ビットマップレンダリングエンジン８０は、ビットマップの生成を指示するためのスタイルシートに存在する"インストリーム外部オブジェクト（instream foreign object）"を利用してもよい。その後、ビットマップ９２は、バーコードプリンタによるバーコードラベルの後印刷のために、プリンタドライバ５４（図１）に対して送られる。

上述したように、スキーマは、全ての入力データストリーム９０、特に基値データを検証するように機能し、誤りが典型的にみつけられる。実際には、変更がバーコードラベルの形式又は内容に対して行われる場合には、誤りはしばしば不用意に導入される。

スキーマ文書の名前及び位置は、バーコードラベルを印刷するリクエストに対応するＸＭＬ入力データストリーム９０に含まれる。スキーマ検証モジュール１１０と協調するＸＭＬプロセッサ７０は、基値データを検証する。スキーマの使用は、最終出力、すなわち、バーコードラベル又は"発送ラベル"に関する誤り及び脱落を防ぐことから、コスト的に有効である。

誤りを有していたときにＸＭＬ入力データストリーム９０が拒絶される又はフラグがたてられた場合には、エラーメッセージがソース８８に対して返信されてもよい。これは、誤りを訂正するように、フラグをたてる又は人間の介在を引き起こすかもしれない。例えば、この特定の例において、ソースは、ＥＲＰシステム８８である。このように、データは、全ての要求されたラベル及びバーコード規則に応じることを保証するための処理に先だって、最初に検査される。

これは、コンプライアンス・ラベリングに対処する場合には、特に有益かもしれない。既知のシステムにおいて、コンプライアンスを要求する者は、コンプライアンス・ラベリングの要求における変更に関してめったにサプライヤに通知しないであろう。そして、サプライヤがこれらの変更又は指示の解釈や実装において誤りを犯した場合には、製造されてコンプライアンスを要求する者に送られた製品に適用されたラベルは、誤りを有しているかもしれず、将来のビジネスを危険にさらすか、又は貨幣の罰金を適用することができるかもしれない。

本発明において、コンプライアンスを要求する者は、スキーマ及び／又はＸＳＬＴスタイルシートに直接変更するのが望ましい。例えば、ラベルの物理的なレイアウトが変更された場合、又は要素名が変更された場合には、コンプライアンスを要求する者は、ＸＳＬＴスタイルシートを変更するであろう。同様に、基値データが追加又は削除された場合、又はそうでなければ資格が与えられた場合（すなわち、郵便番号のための新たに受け入れ可能な数の範囲の場合）には、コンプライアンスを要求する者は、スキーマを変更するかもしれない。このように、サプライヤは、それが変換済のＸＭＬ入力データストリーム９０と一致することを保証するために、そのＥＲＰシステム８８の出力を単に変更する必要がある。ラベルの物理的なレイアウトが変更された場合には、サプライヤは、いかなる変更も全く行う必要がない。

例えば、コンプライアンスを要求する者は、オリジナルの５桁の郵便番号ではなく、９桁の郵便番号が用いられることをここで要求するかもしれない。したがって、コンプライアンスを要求する者は、第１及び第２の郵便番号フィールドの両方を要求するために、スキーマを変更するであろう。そして、第２のフィールドはまた、おそらく００００〜９９９９のある範囲内の数の桁に制限されるであろう。コンプライアンスを要求する者はまた、その変更を提供するために、スタイルシートを変更するかもしれない。それに対するレスポンスにおいて、サプライヤは、ＸＭＬプリンタシステム１０に対して送られたＸＭＬ入力データストリーム９０に現れるように、そのＥＲＰシステムに追加郵便番号フィールドを挿入しなければならない。ＸＭＬ入力データストリーム９０のそのような変更が正確に実行されない場合には、スキーマは、ＥＲＰシステム８８に対して誤りを報告し返すであろう。また、ラベルは、印刷されないであろう。

したがって、サプライヤは、リポジトリ８２，８４から変換済のスキーマ及び／又はスタイルシートにアクセスする必要があるのみであり、受信した場合に基値データに自動的に適用される。本質的に、バーコードラベルの形式及び内容に対する小さな変更、及び重要で大きな変更は、サプライヤにとってわかりやすく、バーコードラベルの内容に対するそのような変更は、スキーマにしたがって検証される。したがって、サプライヤは、コンプライアンスを要求する者によって書き取らせられたバーコードラベルの形式又は内容を変更するコストを招来する必要がなく、そのような変更の実装において誤りをすることができない。誤りがある場合には、そのような誤りは、コンプライアンスを要求する者によって不用意に犯されていたであろう。そして、この人は、サプライヤを非難することができないであろう。

スキーマ文書は、ＸＭＬスキーマリポジトリ８２から得られるのが望ましい。１つの特定の具体例において、スキーマリポジトリ８２は、ＸＭＬプリンタシステム１０及びコンピュータシステム１２に対して外部にあってもよく、コンピュータシステムが接続されたネットワーク、インターネット、又は任意の適切なネットワーク４３，４４を介してアクセスされてもよい。スキーマリポジトリ８２は、複数のスキーマ文書を含んでもよい。したがって、バーコードラベルを生成するための様々なリクエストを表すＸＭＬ入力データストリーム９０は、リポジトリ８２における対応するスキーマの名前及び位置をそれぞれ指定してもよい。リクエストがＸＭＬプロセッサ７０によって受信された場合には、対応するスキーマは、スキーマリポジトリ８２から検索されてもよい。

他の具体例において、ネットワーク４３，４４を介してスキーマリポジトリ８２から得られたスキーマは、ローカルに維持されてもよく、したがって、ハードディスク１８やデータベース２２のようなメモリサブシステム２６（図１）に一時的に存在してもよい。このように、同じスキーマが複数のＸＭＬ入力データストリーム９０又は後のバーコードラベル要求に対して用いられる場合には、ＸＭＬプロセッサ７０は、ネットワーク４３，４４を介して同じスキーマを外部的に検索する必要がないが、むしろメモリサブシステム２６からそのスキーマを検索してもよく、より効率的であるかもしれない。この具体例によれば、コンプライアンスを要求する者は、あるときのみ、外部のリポジトリ８２におけるスキーマを変更又は修正するかもしれない。例えば、コンプライアンスを要求する者は、毎日午前１：００にのみ、スキーマを変更するかもしれない。したがって、サプライヤは、例えばコンプライアンスを要求する者がスキーマの更新を実行した後に、リポジトリ８２からメモリサブシステム２６へとスキーマを１日あたり１度だけ更新する必要があるのみである。その後、サプライヤは、メモリサブシステム２６に一時的に保存されたスキーマが、少なくとも更新が生じる予定であるときまで、最も最近のスキーマ文書であることを知るであろう。

スキーマが得られる位置にかかわらず、スキーマ検証モジュール１１０は、基データの検査及び検証を実行する。スキーマ検証モジュール１１０は、図２においてはＸＭＬプロセッサ７０から分離したブロックとして示されるが、当該スキーマ検証モジュール１１０が作用するデータであるラベル値ノードツリー１００に隣接して図示されるように、例示の目的のためにのみ、この位置において示される。しかしながら、スキーマ検証モジュール１１０は、ＸＭＬプロセッサ７０の部分であってもよく、当該ＸＭＬプロセッサ７０に統合されてもよく、又はこれらから別個とされてもよい。

勿論、スキーマはまた、ＸＭＬ文書であり、したがって、ＸＭＬプロセッサ７０によって処理される。したがって、スキーマの処理結果は、図３に示されるＸＭＬスキーマノードツリー（XML schema node tree）１１４であり、処理されたスキーマの"メモリ表現"又はワーキングモデルである。ＸＭＬスキーマノードツリー１１４は、従来から知られている"文書オブジェクトモデル（document object model；ＤＯＭ）"の形式であってもよい。さらに、ＸＭＬスキーマノードツリー１１４は、ＸＭＬスキーマキャッシュ１１６において示されるように、効率のためのキャッシュメモリに存在してもよい。スキーマ検証モジュール１１０及び／又はＸＭＬプロセッサ７０は、スキーマ文書にしたがって基値データを検証する機能を実行するために、ＸＭＬスキーマノードツリー１１４のデータ上で作動する。

上述したように、誤りがＸＭＬ入力データストリーム９０に存在する場合には、スキーマの適用によって決定されるように、エラーメッセージが生成されてもよい。ＸＭＬ入力データストリーム９０が有効である場合には、データは、本質的に"手をつけない"ままである。その後、ラベル値ノードツリー１００のデータは、ＸＳＬＴスタイルシートを用いて、ＸＳＬＴプロセッサ７４によって処理される。

スタイルシート文書は、ＸＳＬＴスタイルシートリポジトリ８４から得られるのが望ましい。１つの特定の具体例において、スタイルシートリポジトリ８４は、ＸＭＬプリンタシステム１０及びコンピュータシステム１２に対して外部にあってもよく、コンピュータシステムが接続されたネットワーク、インターネット、又は任意の適切なネットワーク４３，４４を介してアクセスされてもよい。スタイルシートリポジトリ８４は、複数のスタイルシートを含んでもよい。したがって、バーコードラベルを生成するための様々なリクエストを表すＸＭＬ入力データストリーム９０は、リポジトリ８４における対応するスタイルシートの名前及び位置をそれぞれ指定してもよい。リクエストがＸＭＬプロセッサ７０によって受信された場合には、対応するスタイルシートは、スタイルシートリポジトリ８４から検索されてもよい。

他の具体例において、ネットワーク４３，４４を介してスタイルシートリポジトリ８４から得られたスタイルシートは、ローカルに維持されてもよく、したがって、ハードディスク１８やデータベース２２のようなメモリサブシステム２６（図１）に一時的に存在してもよい。このように、同じスタイルシートが複数のＸＭＬ入力データストリーム９０又は後のバーコードラベル要求に対して用いられる場合には、ＸＭＬプロセッサ７０は、ネットワーク４３，４４を介して同じスタイルシートを外部的に検索する必要がないが、むしろメモリサブシステム２６からそのスタイルシートを検索してもよく、より効率的であるかもしれない。

この具体例によれば、コンプライアンスを要求する者は、あるときのみ、外部のリポジトリ８４におけるスタイルシートを変更又は修正するかもしれない。例えば、コンプライアンスを要求する者は、毎日午前１：００にのみ、スタイルシートを変更するかもしれない。したがって、サプライヤは、例えばコンプライアンスを要求する者がスタイルシートの更新を実行した後に、リポジトリ８４からメモリサブシステム２６へとスタイルシートを１日あたり１度だけ更新する必要があるのみである。その後、サプライヤは、メモリサブシステム２６に一時的に保存されたスタイルシートが、少なくとも更新が生じる予定であるときまで、最も最近のスタイルシートであることを知るであろう。

勿論、スタイルシートはまた、ＸＭＬ文書であり、したがって、ＸＭＬプロセッサ７０によって処理される。したがって、スタイルシートの処理結果は、図３に示されるＸＳＬＴスタイルシートノードツリー（XSLT stylesheet node tree）１２０であり、処理されたスタイルシートの"メモリ表現"又はワーキングモデルである。ＸＳＬＴスタイルシートノードツリー１２０は、従来から知られている"文書オブジェクトモデル（document object model；ＤＯＭ）"の形式であってもよい。さらに、ＸＳＬＴスタイルシートノードツリー１２０は、ＸＳＬＴスタイルシートキャッシュ１２６において示されるように、効率のためのキャッシュメモリに存在してもよい。ＸＳＬＴプロセッサ７４は、スタイルシートにしたがって基値データ又は基要素名（the underlying element names）を変換する機能を実行するために、ＸＳＬＴスタイルシートノードツリー１２０のデータ上で作動する。

ＸＳＬＴスタイルシートは、図３においてＸＭＬプロセッサ７０に対する入力として示されるが、ＸＳＬＴプロセッサ７４は、スタイルシートを処理することに着目すべきである。全てのＸＭＬ文書が最初に処理され、後処理用の適切なデータ構造に配置されることから、当該ＸＭＬ文書は、ＸＭＬプロセッサ７０に最初に供給される。

ＸＳＬＴプロセッサ７４は、基値データを変更し、位置を変え、再配置してもよく、又は基値データに対して追加してもよく、又は基値データのうちのいくつかを削除してもよい。例えば、スタイルシートの指示のもとに、基値データは、テーブルフォーマット又はカラムに再配置されてもよい。特に、スタイルシートは、ＸＳＬＦＯフォーマット要素及び属性を追加してもよい。

ラベル値ノードツリー１００における基値データが対応するスタイルシートにしたがって処理された後に、ＸＳＬＦＯインスタンスノードツリー（XSLFO instance node tree）１３０が生成される。その上、従来から知られているように、ＸＳＬＦＯインスタンスノードツリー１３０は、文書オブジェクトモジュールの形式であってもよい。ＸＳＬＦＯインスタンスノードツリー１３０は、フォーマット及びレイアウトに関してＸＳＬＦＯプロセッサ７８を指示するＸＳＬＦＯコマンド（レイアウト指示）を含む。そして、ＸＳＬＦＯプロセッサ７８は、ＸＳＬＦＯコマンドを解釈し、基値データを適切にフォーマット及びレイアウトするように、そのようなコマンドを基値データに対して適用する。ＸＳＬＦＯプロセッサ７８は、レンダリング前のフォーマットの最終出力を表すＸＳＬＦＯエリアノードツリー１３０を生成する。

ここで、図３を参照するとともに、"ＸＭＬ入力データストリームについてのコードセグメント１（code segment 1 for an XML input data stream）"と題した直後に示すコードセグメント１を参照する。コードセグメント１は、例えばＥＲＰ又はウェアハウス管理システム８８によってＸＭＬプリンタシステム１０に対して送られるハードコピーにおけるＸＭＬ入力データストリーム９０を示すものである。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

ＸＭＬ入力データストリームについてのコードセグメント１
１＜?xml version="1.0" encoding="UTF-8"?＞
＜?xml-stylesheet type="text/xsl"
href="D:\Projects\XML\Native\Docs\ShipLabels.xsl"?＞
＜labels
５ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"D:\Projects\XML\Native\Docs\ShipLabels.xsd"＞
＜label＞
＜name＞Albert Einstein＜/name＞
１０＜address＞1234 Relative Way＜/address＞
＜city＞Princeton＜/city＞
＜state＞NJ＜/state＞
＜zip＞08540＜/zip＞
＜/label＞
１５＜label＞
＜name＞Steven Hawking＜/name＞
＜address＞5678 Black Hole Drive＜/address＞
＜city＞Los Angeles＜/city＞
＜state＞CA＜/state＞
２０＜zip＞90007＜/zip＞
＜/label＞
＜label＞
＜name＞Richard Feynman＜/name＞
＜address＞90 Quantum Circle＜/address＞
２５＜city＞New York＜/city＞
＜state＞NY＜/state＞
＜zip＞10044＜/zip＞
＜/label＞
＜/labels＞

ＸＭＬ入力データストリームは、スキーマ文書を"ShipLabels.xsd"であるものと識別し、また、そのスキーマ文書は、この特定の例においては、コードセグメント１における第７行目に示されるように、"D:\Projects\XML\Native\Docs"と称されるディレクトリにおいてみつけられる。さらに、ＸＭＬ入力データストリームは、スタイルシート文書を"ShipLabels.xsl"であるものと識別し、また、そのスタイルシート文書は、コードセグメント１における第３行目に示されるように、"D:\Projects\XML\Native\Docs"と称されるディレクトリにおいてみつけられる。勿論、スキーマ文書及びスタイルシート文書は、例えばインターネットアドレスによって識別されるようないかなる場所に配置されてもよい。

この特定の例は、印刷される３つの発送ラベルの基値データ及び要素名を示している。各発送ラベルは、以下のように、かぎ括弧間で定義されたＸＭＬ要素名を含む：＜名前＞、＜住所＞、＜都市＞、＜州＞、及び＜郵便番号＞。第１の要素名＜名前＞の値は、"アルベルト・アインシュタイン（Albert Einstein）"であり、第２の要素名＜住所＞の値は、"リレイティブウェイ１２３４（1234 Relative Way）"であり、第３の要素名＜都市＞の値は、"プリンストン（Princeton）"であり、第４の要素名＜州＞の値は、"ニュージャージー（NJ）"であり、第５の要素名＜郵便番号＞の値は、"０８５４０"である。これは、基値データである。

ここで、図３及びコードセグメント１を参照するとともに、"ＸＭＬスキーマについてのコードセグメント２（code segment 2 for XML schema）"と題した直後に示すコードセグメント２を参照する。コードセグメント２は、コードセグメント１のＸＭＬ入力データストリームにおいて指定されたＸＭＬスキーマ文書の形式をしているＸＭＬ文書の特定の例を示すものである。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

ＸＭＬスキーマについてのコードセグメント２
１＜?xml version="1.0" encoding="UTF-8"?＞
＜xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"＞
５＜xs:element name="address" type="xs:string"/＞
＜xs:element name="city" type="xs:string"/＞
＜xs:element name="label"＞
＜xs:complexType＞
＜xs:sequence＞
１０＜xs:element ref="name"/＞
＜xs:element ref="address"/＞
＜xs:element ref="city"/＞
＜xs:element ref="state"/＞
＜xs:element ref="zip"/＞
１５＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name="labels"＞
＜xs:complexType＞
２０＜xs:sequence＞
＜xs:element ref="label" maxOccurs="unbounded"/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
２５＜xs:element name="name" type="xs:string"/＞
＜xs:element name="state"＞
＜xs:simpleType＞
＜xs:restriction base="xs:string"＞
＜xs:enumeration value="CA"/＞
３０＜xs:enumeration value="NJ"/＞
＜xs:enumeration value="NY"/＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜/xs:element＞
３５＜xs:element name="zip"＞
＜xs:simpleType＞
＜xs:restriction base="xs:int"＞
＜xs:minInclusive value="00000"/＞
＜xs:maxInclusive value="99999"/＞
４０＜/xs:restriction＞
＜/xs:simpleType＞
＜/xs:element＞
＜/xs:schema＞

上述したように、スキーマは、基値データを検証するために用いられる。これは、全ての要求されたデータが存在することを決定するために検査を要し、外来のデータは、存在せず、データの存在は、指定された範囲内等にある。いかなる適切な検証スキームは、アプリケーションに応じて、スキーマにおいて指定されてもよい。ＸＭＬ言語は、強固であり、コードは、莫大数の要求を扱うために記載されてもよい。

例えば、上述したコードセグメント２において示されるスキーマ文書は、コードセグメント２における第５行目によって示されるように、要素名＜住所＞に対応する基値データが、ＸＭＬスキーマ仕様に定義されるストリング（string）であるに違いないことを明示する。スキーマ文書はまた、コードセグメント２における第９行目〜第１５行目に示されるように、要素名＜名前＞、＜住所＞、＜都市＞、＜州＞、及び＜郵便番号＞に対応する基値データが、示されたシーケンスに存在するに違いないことを明示する。さらに、コードセグメント２において示されるこの特定のスキーマ文書は、要素名＜州＞に対応する基値データが、３つの州、すなわち、"カリフォルニア州（CA）"、"ニュージャージー州（NJ）"、"ニューヨーク州（NY）"のうちの１つの州であるに違いないことを明示する。勿論、これは略例のみであり、全ての州が例示の目的のためにのみ含まれるとは限らない。コードセグメント２において示されるスキーマ文書はまた、要素名＜郵便番号＞に対応する基値データが０００００から９９９９９までの範囲にあるに違いないことを明示する。ＸＭＬ入力データストリームのデータが上述したスキーマ基準のうちのいずれをも満たさない場合には、スキーマ検証モジュール１１０は、それを拒絶し、望ましくはソース８８に対してエラーメッセージを返信するであろう。

ここで、図３及びコードセグメント１，２を参照するとともに、"ＸＳＬＴスタイルシートについてのコードセグメント３（code segment 3 for an XSLT stylesheet）"と題した直後に示すコードセグメント３を参照する。コードセグメント３は、コードセグメント１のＸＭＬ入力データストリームにおいて指定されたＸＳＬＴスタイルシート文書の形式をしているＸＭＬ文書の特定の例を示すものである。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

ＸＳＬＴスタイルシートについてのコードセグメント３
１＜?xml version="1.0" encoding="UTF-8"?＞
＜xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
５ xmlns:bo=http://www.zebra.com/2002/XSL/Barcode＞
＜xsl:output method="xml" version="1.0" indent="yes" /＞
＜xsl:template match="labels"＞
＜fo:root＞
＜fo:layout-master-set＞
１０＜fo:simple-page-master master-name="all-labels"＞
＜fo:region-body margin="1in" /＞
＜/fo:simple-page-master＞
＜/fo:layout-master-set＞
＜fo:page-sequence master-name="all-labels"＞
１５＜fo:flow flow-name="xsl-region-body" font="12pt Times"＞
＜xsl:apply-templates /＞
＜/fo:flow＞
＜/fo:page-sequence＞
＜/fo:root＞
２０＜/xsl:template＞
＜xsl:template match="label"＞
＜fo:block break-after="page"＞
＜xsl:apply-templates select="name" /＞
＜xsl:apply-templates select="address" /＞
２５＜fo:block font="bold 14pt Times" text-align="left"＞
＜xsl:apply-templates select="city" /＞
＜xsl:apply-templates select="state" /＞
＜/fo:block＞
＜xsl:apply-templates select="zip" /＞
３０＜fo:block＞
＜fo:instream-foreign-object＞
＜bo:barcode＞
＜bo:postnet interpretation-line="none"＞
＜xsl:value-of select="zip" /＞
３５＜/bo:postnet＞
＜/bo:barcode＞
＜/fo:instream-foreign-object＞
＜/fo:block＞
＜/fo:block＞
４０＜/xsl:template＞
＜xsl:template match="name"＞
＜fo:block font="bold 14pt Times" text-align="left"＞
＜xsl:value-of select="." /＞
＜/fo:block＞
４５＜/xsl:template＞
＜xsl:template match="address"＞
＜fo:block font="bold 14pt Times" text-align="left"＞
＜xsl:value-of select="." /＞
＜/fo:block＞
５０＜/xsl:template＞
＜xsl:template match="city"＞
＜xsl:value-of select="." /＞
＜/xsl:template＞
＜xsl:template match="state"＞
５５＜xsl:text＞,＜/xsl:text＞
＜xsl:value-of select="." /＞
＜/xsl:template＞
＜xsl:template match="zip"＞
＜fo:block font="bold 14pt Times" text-align="left"＞
６０＜xsl:value-of select="." /＞
＜/fo:block＞
＜/xsl:template＞
＜/xsl:transform＞

上述したように、スタイルシートは、データを変換するために用いられる。この特定の例において、コードセグメント３のスタイルシートは、ＸＳＬＦＯプロセッサ７８に関して上述した２つのタイプのネームスペース（namespace）、すなわち、"バーコードタイプオブジェクト（barcode-type object）"であるために選択される"bo"タイプオブジェクト、及びフォーマットオブジェクト（formatting object）であるために選択される"fo"タイプオブジェクトを定義する。従来から知られているように、これは、異なるオブジェクト間の区別を可能とする。スタイルシートは、いくつかのデータを変形させるか又は追加さえ引き起こしてもよい。例えば、コードセグメント１のＸＭＬ入力データストリームからの基値データ、すなわち、第４０行目〜第６２行目によって示されるように、"アインシュタイン（Einstein）"、"リレイティブウェイ１２３４（1234 Relative Way）"等が挿入される。

このスタイルシートはまた、フォーマット要素又はＸＳＬＦＯオブジェクトとして指定される様々な"fo"タイプ要素を生成させる。ＸＳＬＦＯオブジェクトは、ＸＳＬＦＯプロセッサ７８が"理解"して処理するレイアウトタイプコマンドを含む。"fo"の接頭辞を有するコードの全ての行がＸＳＬＴプロセッサ７４によって解釈されるとは限らず、むしろＸＳＬＦＯプロセッサ７８に渡されることに着目すべきである。

例えば、コードセグメント３の第２１行目は、第２２行目の＜fo:block break-after = "page"＞が後続する＜xsl: template match= "label"＞を示している。これは、コードセグメント１において指定された３つの発送ラベル間の"ページ破損（page break）"を置くために、ＸＳＬＦＯプロセッサ７８によって解釈される。本質的に、新たな発送ラベルは、コードセグメント１において指定された基値データを含む個々の新たな発送ラベルとともにページ破損（page break）によって生成される。

さらに、この特定のスタイルシートは、第３１行目に示されるように、"インストリーム外部オブジェクト"が挿入されることを明示する。第３１行目は、第３１行目〜第３７行目とともに＜fo:instream-foreign-object＞として示され、インストリーム外部オブジェクトを定義する。ＸＳＬＴプロセッサ７４又はＸＳＬＦＯプロセッサ７８のいずれかによってインストリーム外部オブジェクトが処理されないことに着目すべきである。より正確にいえば、インストリーム外部オブジェクトは、ビットマップ／バーコードレンダリングエンジン８０に渡され、当該ビットマップ／バーコードレンダリングエンジン８０によって処理される。例えば、コードセグメント３の第３２行目〜第３６行目は、"ポストネット（postnet）"バーコード要素の定義を含む＜bo:barcode＞要素が挿入されることを引き起こす。要素は、ビットマップ／バーコードレンダリングエンジン８０によって後に処理されるであろう。第３４行目では、ＸＳＬＴプロセッサ７４は、ＸＭＬ入力データストリームからの郵便番号が＜bo:postnet＞要素のテキストとして挿入されることを引き起こす。

ここで、図３及びコードセグメント１〜３を参照するとともに、"ＸＳＬＴインスタンスノードツリー表現についてのコードセグメント４（code segment 4 for an XSLT instance node tree representation）"と題した直後に示すコードセグメント４を参照する。コードセグメント４は、コードセグメント３のスタイルシートと協調するＸＳＬＴプロセッサ７４によって生成されるＸＳＬＦＯインスタンスノードツリー１３０の出力の表現の特定の例を示すものであり、その出力は、ＸＳＬＦＯプロセッサ７８に供給されるＸＳＬＦＯインスタンスノードツリーの表現である。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

ＸＳＬＴインスタンスノードツリー表現についてのコードセグメント４
１＜?xml version="1.0" encoding="UTF-16"?＞
＜fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:bo=http://www.zebra.com/2002/XSL/Barcode＞
＜fo:layout-master-set＞
５＜fo:simple-page-master master-name="all-labels"＞
＜fo:region-body margin="1in" /＞
＜/fo:simple-page-master＞
＜/fo:layout-master-set＞
＜fo:page-sequence master-name="all-labels"＞
１０＜fo:flow flow-name="xsl-region-body" font="12pt Times"＞
＜fo:block break-after="page"＞
＜fo:block font="bold 14pt Times" text-
align="left"＞Albert Einstein＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞1234
１５ Relative Way＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞Princeton, NJ＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞08540＜/fo:block＞
２０＜fo:block＞
＜fo:instream-foreign-object＞
＜bo:barcode＞
＜bo:postnet interpretation-
line="none"＞08540＜/bo:postnet＞
２５＜/bo:barcode＞
＜/fo:instream-foreign-object＞
＜/fo:block＞
＜/fo:block＞
＜fo:block break-after="page"＞
３０＜fo:block font="bold 14pt Times" text-
align="left"＞Steven Hawking＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞5678 Black Hole Drive＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞Los
３５ Angeles, CA＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞90007＜/fo:block＞
＜fo:block＞
＜fo:instream-foreign-object＞
４０＜bo:barcode＞
＜bo:postnet interpretation-
line="none"＞90007＜/bo:postnet＞
＜/bo:barcode＞
＜/fo:instream-foreign-object＞
４５＜/fo:block＞
＜/fo:block＞
＜fo:block break-after="page"＞
＜fo:block font="bold 14pt Times" text-
align="left"＞Richard Feynman＜/fo:block＞
５０＜fo:block font="bold 14pt Times" text-
align="left"＞90 Quantum Circle＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
align="left"＞New York, NY＜/fo:block＞
＜fo:block font="bold 14pt Times" text-
５５ align="left"＞10044＜/fo:block＞
＜fo:block＞
＜fo:instream-foreign-object＞
＜bo:barcode＞
＜bo:postnet interpretation-
６０ line="none"＞10044＜/bo:postnet＞
＜/bo:barcode＞
＜/fo:instream-foreign-object＞
＜/fo:block＞
＜/fo:block＞
６５＜/fo:flow＞
＜/fo:page-sequence＞
＜/fo:root＞

上記コードセグメント４の２つの主部分、すなわち、コード＜fo:layout-master-set＞をともなって第４行目で始まる第１の部分、及びコード＜fo:page-sequence master-name="all-labels"＞をともなって第９行目で始まる第２の部分は、簡潔に記述される。コードのこの部分は、本質的に、バーコードラベルがどのように"みえる（look like）"か、又はバーコードラベルがどのように"レイアウトされる（laid-out）"であろうか、及び基値データがそのレイアウトにおいてどのように現れるであろうかを定義する。

例えば、コードセグメント１において示される基値データのフォーマットに関して、第１２行目〜第１３行目に示される"bold 14pt Times"のフォント属性、及びtext-align = "left"は、バーコードラベルが印刷される場合に、"アルベルト・アインシュタイン（Albert Einstein）"の名前が１４ポイントのタイムズフォントで印刷されるとともに、バーコードラベルの左側マージンに配列されるように、"アルベルト・アインシュタイン（Albert Einstein）"の基値データに適用されるであろう。従来から知られているように、異なる種類のフォーマット指示が指定されてもよく、それはＸＳＬＦＯプロセッサ７８によって解釈されるであろう。

さらに、ＸＳＬＦＯインスタンスノードツリー１３０の表現のこの特定の例は、コードセグメント４の第２１行目〜第２６行目に示されるように、インストリーム外部オブジェクトを含む。インストリーム外部オブジェクトは、ＸＳＬＦＯプロセッサ７８によって処理されなくてもよい。より正確にいえば、インストリーム外部オブジェクトは、処理のためにビットマップ／バーコードレンダリングエンジン８０に渡されてもよい。処理におけるこの点で、ＸＳＬＦＯプロセッサ７８は、バーコード要素タイプがＸＳＬＦＯ仕様に含まれていないことから、バーコードラベルを印刷する方法を"知らない"ことに着目すべきである。より正確にいえば、コードセグメント１，２に示されたように、基値データ、すなわち、"アインシュタイン（Einstein）"、"リレイティブウェイ１２３４（1234 Relative Way）"等のようなテキスト情報のみを、テキストとしてバーコードラベル上に印刷することができる。ＸＳＬＦＯプロセッサ７８がバーコードシンボルを生成する方法を"知らない"ことから、実際のバーコードシンボルは現れない。

ＸＳＬＦＯプロセッサ７８による処理結果は、ＸＳＬＦＯエリアノードツリー（XSLFO area node tree）１４０である。コードセグメント４において示されるインストリーム外部オブジェクトがＸＳＬＦＯプロセッサ７８によって処理されずに、むしろＸＳＬＦＯエリアノードツリー１４０の１つ以上のノードにおいてバーコード／ビットマップレンダリングエンジン８０に渡されることに着目すべきである。インストリーム外部オブジェクト要素は、＜bo:barcode＞として引用され、コードセグメント４の第２１行目〜第２６行目に示される。バーコード／ビットマップレンダリングエンジン８０は、＜bo:barcode＞要素を受信し、そのブロックに含まれるコードを処理する。例えば、レンダリングエンジン８０は、この特定のノードを要素の"ポストネット（postnet）"バーコードタイプであるものとして定義するように、第２３行目〜第２４行目、すなわち、＜bo:postnet interpretation-line="none"＞08540＜bo:postnet＞を解釈する。後述する対応する業界標準によって定義されるように、バーコードシンボルの様々な"タイプ"が定義されてもよい。

バーコードシンボルとして印刷される基値データは、コードセグメント４の第２４行目に示されるように、数字データ"０８５４０"であり、コードセグメント１において示されるアルベルト・アインシュタインの住所に関連した郵便番号である。この特定の例においては、郵便番号のみがバーコードシンボルに変換される。勿論、アプリケーションに応じて、任意の全ての情報をバーコードシンボルに変換してもよい。また、この特定の例において、コードセグメント４において示されるインストリーム外部オブジェクトは、コードセグメント１において示される３つの郵便番号のみ関係がある。他の基値データは、この例におけるバーコードシンボルに変換されない。

ここで、コードセグメント４とともに図２乃至図４を参照すると、バーコード／ビットマップレンダリングエンジン８０に関する付加的な詳細、及びインストリーム外部オブジェクトの処理が述べられる。上述したように、レンダリングエンジン８０は、ＸＳＬＦＯプロセッサ７８によって生成されたＸＳＬＦＯエリアノードツリー１４０の各ノードを処理する。従来から知られているように、ＸＳＬＦＯエリアノードツリー１４０は、文書オブジェクトモデルとしてメモリに表現される。したがって、複数のノードが存在してもよい。例えば、あるノードは、インストリーム外部オブジェクトを含んでもよく、他のノードは、関連する要素名を含んでもよく、他のノードは、関連するテキストデータを含んでもよく、他のノードは、関連する属性等を含んでもよい。

図４におけるブロック１５０に示されるように、ＸＳＬＦＯエリアノードツリー１４０のノードは処理される。特に、レンダリングエンジン８０は、インストリーム外部オブジェクトによって定義された実際のバーコードシンボルをレンダリングする又は生成する方法を"知っている"。商業上利用可能なＸＳＬＦＯプロセッサは、バーコードシンボルを表すそのようなインストリーム外部オブジェクトを処理する方法を"知らず"、これにより、バーコードシンボルを生成又はレンダリングすることができない。しかしながら、商業上利用可能なＸＳＬＦＯプロセッサは、受け入れ可能な方法でテキストをレンダリングしてもよく、あるタイプのインストリーム外部オブジェクトをさらにレンダリングしてもよい。

それが例えばテキストデータを含んでもよいことを意味して、特定のノードがインストリーム外部オブジェクトを含んでいない場合には、このノードは、ブロック１５４において図示されるように、レンダリングエンジン８０ではなくＸＳＬＦＯプロセッサ７８の処理能力を利用することにより、"標準"方法で処理されてもよい。１つの具体例において、非インストリーム外部オブジェクトは、ＸＳＬＦＯプロセッサ７８に供給され"返される"か、又は、ＸＳＬＦＯプロセッサは、ＸＳＬＦＯエリアノードツリー１４０における特定のノードがそれによって処理するのに適切であるものと通知される。

非インストリーム外部オブジェクトを含むＸＳＬＦＯエリアノードツリー１４０におけるノードの処理は、上述したように、ＸＳＬＦＯプロセッサ７８によって処理されてもよい。勿論、異なる商業上利用可能なＸＳＬＦＯプロセッサは、例えば異なるフォーマットにテキストをレンダリングする。例えば、アンテナハウス社（Antenna House Corporation）製の"ＸＳＬフォーマッタ（XSL Formatter）"と称されるＸＳＬＦＯプロセッサは、上述したように、ＷＩＮＤＯＷＳ（登録商標）"デバイスインディペンデントビットマップ（device-independent bitmap）"フォーマットにノードをレンダリングする。上述したように、レンダーエックス社（RenderX Corporation）製の"ＸＥＰ"として引用されたＸＳＬＦＯプロセッサは、"ＰＤＦ"フォーマットにノードをレンダリングし、アパッチ・ソフトウェア・ファウンデーション（the Apache Software Foundation）製の"ＦＯＰ"として引用されたＸＳＬＦＯプロセッサはまた、"ＰＤＦ"フォーマットにノードをレンダリングしてもよい。

ＸＭＬプリンタシステム１０は、アパッチ・ソフトウェア・ファウンデーション（the Apache Software Foundation）製の"ＦＯＰ"をＸＳＬＦＯプロセッサ７８として利用するのが望ましい。このＸＳＬＦＯプロセッサは、処理することができないインストリーム外部オブジェクトに遭遇した場合に、サブルーチン又は他の処理関数を"呼び出す（call）"ように形成されてもよいためである。特に、このＸＳＬＦＯプロセッサ７８は、処理することができないインストリーム外部オブジェクトを扱うために、ここに記述されるレンダリングエンジンソフトウェアブロック８０を呼び出すように設定されてもよい。

続いて、ブロック１６０において示されるように、ノードがＸＳＬＦＯプロセッサ７８によって処理することができないバーコードを表すインストリーム外部オブジェクトを含む場合には、レンダリングエンジン８０は、インストリーム外部オブジェクトがこのＸＭＬプリンタシステム１０に特有の"ネームスペース（namespace）"を有しているか否かを決定するために検査する。例えば、レンダリングエンジン８０は、"ゼブラ社ネームスペース（Zebra corporation namespace）"に対応するインストリーム外部オブジェクトに関連したネームスペースが相当するか否かを決定するために検査してもよい。ネームスペースの記法は、従来から知られている。これは、"xmlns:bo=http://www.zebra.com/2002/XSL/Barcode＞"として、コードセグメント４の第３行目に示される。したがって、コードセグメント４に示されるように、上記で定義されたネームスペースは、"bo"の接頭辞を有する任意の要素に適用される。そして、"bo"の接頭辞を有するような要素は、レンダリングエンジン８０による処理のためにのみ利用可能である。"bo"の接頭辞タイプ要素は、バーコードタイプインストリーム外部オブジェクトに対応する。ＸＳＬＦＯプロセッサ７８は、そのような要素を処理する方法を"知らないであろう"。

インストリーム外部オブジェクトが適切なネームスペースに関連していない場合には、ＸＳＬＦＯプロセッサがインストリーム外部オブジェクトのいくつかの制限のある数を処理することができるかもしれないことから、バーコードタイプのインストリーム外部オブジェクトではないと仮定して、当該インストリーム外部オブジェクトは、ＸＳＬＦＯプロセッサ７８に戻される。これは、ブロック１６０からブロック１５４までの矢印１６２によって示される。しかしながら、一般に、インストリーム外部オブジェクトは、インストリーム外部オブジェクトに関連したデータが性質（バーコードのような)において非常にユニークであるという特定の理由のために、存在する又は生成される。したがって、多くの商業上利用可能又は汎用目的のＸＳＬＦＯプロセッサは、それらを処理することができない。

ここに述べられた商業上利用可能なＸＳＬＦＯプロセッサは、全てのインストリーム外部オブジェクトを必ずしも処理することができないことに着目すべきである。しかしながら、それらは、バーコードシンボルに対応するインストリーム外部オブジェクトを処理することができない。

そのインストリーム外部オブジェクトが適切なネームスペースを有していると仮定して、ブロック１７０は、バーコードタイプを決定するために、インストリーム外部オブジェクトにおける要素を解釈する。例えば、インストリーム外部オブジェクトは、コードセグメント４の第２１行目〜第２６行目に示される。より明確には、バーコードに対応する正確なネームスペースを示す"bo"の接頭辞を有するバーコード要素は、コードセグメント４の第２３行目〜第２４行目に示されるように、バーコードタイプの"ポストネット（postnet）"を有するように示され、＜bo:postnet interpretation-line="none"＞08540＜/bo:postnet＞として現れる。コードセグメント４の第４１行目〜第４２行目は、コードセグメント１において示される"スティーブン・ホーキング（Steven Hawking）"の住所に対応する他のインストリーム外部オブジェクト、すなわち、印刷される次のバーコードラベルについての同様のバーコード要素を示すことに着目すべきである。

いかなるバーコードタイプが、アプリケーションに応じて、インストリーム外部オブジェクトにおいて指定されてもよい。バーコードタイプは、既知のバーコード基準に基づく。例えば、バーコードタイプは、ポストネットタイプのバーコードシンボルに制限されず、"Ｉｎｄｕｓｔｒｉａｌ２ｏｆ５"、"ＰＤＦ４１７"、"ＵＰＣ"等であってもよい。バーコード"タイプ"は、バーの厚さ、バー間の間隔幅に対するバーの厚さの比率等のような印刷されるバーコードシンボルの基本構造を指定する。個々の特定の既知のバーコード基準は、具体的に定義される。

続いて、バーコードタイプがインストリーム外部オブジェクトから確認された後、ブロック１７６において示されるように、インストリーム外部オブジェクトの属性は、バーコード特性を決定するために解釈される。特性は、バーコードシンボルが生成される方法を変更してもよい。例えば、"ポストネット（postnet）"タイプバーコードの１つの属性は、"interpretation-line="none""として、コードセグメント４の第２３行目〜第２４行目にみられる。従来から知られているように、"interpretation-line="none""は、特定のバーコードシンボルに沿っては対応する人間の判読可能なテキストが生成されないことを意味する。バーコード要素に関連した属性の他の例は、バーコードシンボルの高さであってもよく、それはまた、属性としてインストリーム外部オブジェクトにおいて指定されてもよい。

そして、レンダリングエンジン８０は、インストリーム外部オブジェクトから得られたバーコードタイプ及び属性を用いて、ブロック１８０において示されるように、バーコードシンボルに変換される実際のノードテキストデータを得る。この例において、実際のバーコードデータは、コードセグメント４の第２４行目における逆かぎ括弧（＞８０５４０＜）の間に示されるように、郵便番号"０８５４０"である。（例えばリニアバーコードについての）バーコードシンボルのライン又はバーを表す数字データ"８０５４０"からビットマップへの物理的な変換は、例えばゼブラ社（Zebra Corporation）製のバーコードラベルプリンタに含まれるソフトウェアルーチンによって実行されてもよい。そのような適切なバーコードプリンタは、例えばモデルＸｉシリーズ・バーコードプリンタ（ＸｉＩＩＩ＋、９０ＸｉＩＩＩ、９６ＸｉＩＩＩ、１４０ＸｉＩＩＩ、１７０ＸｉＩＩＩ、２２０ＸｉＩＩＩ等）、２８００シリーズ・バーコードプリンタ、モデルＺ４Ｍ，Ｚ６Ｍ，１０５ＳＬバーコードプリンタ等を含んでもよい。ゼブラ社製のバーコードプリンタに含まれるそのような既知のソフトウェアルーチン又はアルゴリズムは、非常に効率的である。したがって、バーコードは、迅速にレンダリングされる。

リニアバーコードについては、テキストデータをその相対的な幅がバーコード記号体系についての業界仕様に合致する一連の明暗のバーに変換することにより、ビットマップがレンダリングされる。テキストデータは、それがバーコードスキャナによって読まれる場合には、バーコードの検証を可能とするように符号化する前に、検査文字を追加してもよい。検査文字は、要求されてもよく、又は記号体系に応じてオプションとしてもよい。バーは、記号体系の符号化の要求に応じたバーのモジュールにグループ化されてもよい。テキストデータは、記号体系に応じて符号化する際に圧縮されてもよい。バーは、記号体系仕様によって定義されるような１本以上の"ファインダ（finder）"バーに先行及び／又は後続されてもよく、それは、スキャナがバーコードデータをより容易にみつけることを可能とする。

記号体系によって要求された適切な符号化及び適切な物理的寸法について必要とされるときには、他のアルゴリズムが適用されてもよい。バーの高さ、狭いバーの幅、広いバーと狭いバーとの比率、及び他の記号体系特定パラメータが、ＸＭＬデータにおける属性によって指定されてもよい。さらに、ＸＭＬデータにおける属性によって指定されるように、バーコードビットマップは、（通常９０°のインクリメントにおいて）回転されてもよい。

２次元バーコードについては、テキストデータを様々なユニークな記号体系アルゴリズムにしたがってビットパターンに変換することにより、ビットマップがレンダリングされる。２次元バーコードは、典型的には、リニアバーコードよりも多くのテキストデータの符号化を可能とする。符号化アルゴリズムは、例えば、データ冗長度、モジュール化、ファインダパターン、及び記号体系によって定義されるような他のアルゴリズムのレベルを変化させて、データ圧縮、誤り検査及び訂正を含んでもよい。ユーザ指定可能な記号体系仕様パラメータは、ＸＭＬデータにおける属性によって指定されてもよい。そして、記号体系アルゴリズムによって生成されたビットマップは、ＸＭＬデータにおける属性によって指定されるように、拡大及び／又は回転されてもよい。

一旦ビットマップ表現バーコードシンボルがブロック１８０によって生成されると、ビットマップは、"マスタ（master）"又は"ラベル（label）"ビットマップ１８４に配置される又は結合され、ラベルビットマップは、ブロック１８２において示されるように、発送ラベル全体のイメージを表す。発送ラベルは、人間が判読可能なテキスト、他のテキスト、又は文字、及びバーコードシンボルを含む。上述したビットマップは、別個であってもよいことに着目すべきである。すなわち、テキストについてのビットマップ及びバーコードシンボルについてのビットマップ、又はあるマスタビットマップは、用いられる又は処理進行として"構成される（populated）"てもよい。その点では、レンダリングエンジン８０が作動するツリー又はデータ構造は、異なる"エリア"を含むことを意味する"ＸＳＬＦＯエリアノードツリー"と称されることに着目すべきである。そのようなエリアは、異なる若しくは個々のビットマップ又はビットマップ部分に対応してもよい。しかしながら、いかなる数の適切なビットマップ構造が使用されてもよい。ビットマップの正確な構造若しくは配置、又はビットマップの数は、本発明の範囲に対して直接的に関連するものではない。

例えば、テキストを生成する場合には、ＸＳＬＦＯプロセッサ７８は、１つの特定のビットマップにおける"その（its）"テキストに配置されてもよい。そのようなテキストは、上述した"アルベルト・アインシュタイン（Albert Einstein）"に対応してもよい。このテキストはまた、バーコードシンボルとともに発送ラベル上に印刷されることから、"マスタ（master）"又は"ラベル（label）"ビットマップ１８４は、ビットマップのコンポーネントを全て含むであろう。そして、最終の"マスタ（master）"ビットマップ１８４は、発送ラベルが印刷されるように、プリンタドライバ５４（図１）に対して送られる。

ここで、図４及び図５を参照すると、図５は、コードセグメント１における指定された第１のバーコード発送ラベルについての上述した処理の最終出力の表現１９０である。上述したように、レンダリングエンジン８０により、テキストデータは、対応するスタイルシートにしたがってレンダリングされるとともにフォーマットされ、一方、郵便番号１９２はまた、バーコードシンボルの形式にレンダリングされる。例示の目的のためであることに着目すべきであり、図５において示されるフォントサイズ又はフォントタイプは、コードセグメント３において示される対応するスタイルシートにおいて指定されたものと同じでなくてもよい。

ここで、図６を参照すると、代替具体例が示される。同様の参照符号が同様の構造を指示するために用いられる。この特定の具体例において、ＸＭＬプリンタシステム１０は、全ての実例におけるＸＭＬプリンタ装置を含む必要がない又は特に利用する必要がない。この具体例において、例えば、外部リクエスタ１９４は、バーコードラベルを印刷することができるように、ビットマップにレンダリングされたＸＭＬ入力データストリームを有することを望んでもよく、リモートで行われてもよい。したがって、外部リクエスタ１９４は、インターネット又は他のネットワーク４３，４４上のＸＭＬサーバ２００に対してリクエストを送ってもよい。そのリクエストは、図１乃至図３及びコードセグメント１乃至コードセグメント４に関して上述したＸＭＬ入力データストリームと同じ形式であってもよい。そのリクエストはまた、従来から知られているように、ＳＯＡＰ（Simple Object Access Protocol）のようなＸＭＬデータを含むプロトコルの形式であってもよい。

これを受けて、ＸＭＬサーバ２００のコンピュータシステム１２は、ＸＭＬ入力データストリームを処理してもよい。上述した同様の処理機能は全て、プリンタドライバに対してビットマップが送られないことを除いて、この具体例において実行される。より正確にいえば、ビットマップは、従来から知られている"ＪＰＥＧ"又は"ＰＮＧ"フォーマットのような任意の適切なフォーマットに変換される。そして、ＪＰＥＧ又はＰＮＧファイルは、外部リクエスタ１９４に対して送り返され、当該外部リクエスタ１９４は、その後、適切なプリンタドライバ用のＪＰＥＧ又はＰＮＧファイルをフォーマットし、バーコードラベルを印刷及び／又は表示する。したがって、本発明は、バーコードレンダリングサーバとして機能してもよく、また、必ずしも印刷機能を実行する必要がない。

ここで、図１のプリンタシステムの代替具体例を図７及び図８に示す。それは、図２乃至図６において示される"ネイティブ（native）"ＸＭＬプリンタシステム１０ではなく、"ハイブリッド（hybrid）"ＸＭＬプリンタシステム３００を示している。この具体例は、図１において示されるコンピュータシステム１２及びプリンタシステム５０とともになお用いられてもよいことに着目すべきである。同様の参照符号が同様の構造又はコンポーネントを指示するために用いられる。

この具体例において、ハイブリッドＸＭＬプリンタシステム３００は、ＺＰＬＩ及び／又はＺＰＬＩＩのようなＺＰＬ言語（ゼブラプログラミング言語（Zebra Programming Language））、及びそれらの任意の変形と同様であるＺＰＬデータテンプレートに基づくＸＭＬデータを受信してもよい。ＺＰＬ言語は、"キャレット（caret）"文字を用いるフォーマット言語及びコマンドを定義する２つの文字コマンドコードである。例えば、"^XA"コマンドは、新たなラベルフォーマットの開始を定義し、"^XZ"コマンドは、ラベルフォーマットの終了を定義する。

ＺＰＬ言語はまた、制御コマンドを表す"ティルド（tilde）"コマンドを含む。例えば、コマンド"^〜ＪＲ"は、プリンタリセットコマンドであり、それは、プリンタによって直ちに作用され、実際にバーコードラベルの実際のフォーマットと重要な関係を有しない。ＺＰＬＩ及びＺＰＬＩＩは、本発明の所有者であるイリノイ州ヴァーノンヒルズ（Vernon Hills, Illinois）のゼブラ社（Zebra Corporation）によって開発された。ＺＰＬは、ここに、ＺＰＬＩＩと交換可能に用いられることに着目すべきである。

ＺＰＬ言語仕様に関するより重要な詳細は、"ＺＰＬＩＩプログラミングガイド第１巻：Ｘ．１０についてのコマンド参照"製造部門番号４５５４１ＬＢ（"ZPL II Programming Guide Volume One: Command Reference for X.10"Manufacturer Part No. 45541LB）と題する文書と、文書"ＺＰＬＩＩプログラミングガイド第２巻：Ｘ．１０環境"製造部門番号４５５４２ＬＢ（"ZPL II Programming Guide Volume Two: The X.10 Environment"Manufacturer Part No. 45542LB）と題する文書とでみつかるかもしれず、これら文書は、以下のインターネットウェブアドレス"www.zebra.com/SS/manuals.htm"のゼブラ社のウェブサイトでみつけられてダウンロードされるかもしれない。上述した文書は、その全体を参照することによってここに組み入れられる。図７乃至図９の具体例において、プリンタシステムの"言語（language）"は、ＺＰＬ及びＸＭＬの両方のハイブリッドであり、これにより、プリンタシステム１０は、"ハイブリッドＸＭＬプリンタ"と称される。

知られているように、ＺＰＬに基づくプリンタは、"オンデマンド印刷（on demand printing）"及び"格納されたラベルフォーマット（stored label format）"を扱うことができる。オンデマンド印刷は、印刷されるラベルデータを含むデータストリームがプリンタに対して送られた場合には、それが直ちに印刷されることを意味する。格納されたラベルフォーマットは、ラベルについてのテンプレートが予め生成されてもよく、プリンタにダウンロードされてもよいことを意味する。そして、テンプレートは、印刷されるラベルデータを含む後で送信されたデータストリームとともに用いるために、プリンタ内で内部的に再度呼び出されてもよい。

以下の記述においてより明確になるように、図２乃至図６のネイティブＸＭＬプリンタシステム具体例と、図７及び図８のハイブリッドＸＭＬプリンタシステム具体例との１つの相違点は、ハイブリッドＸＭＬプリンタシステム具体例においては、データテンプレートが、ＺＰＬにおいて予め定められ、まずプリンタにダウンロードされるということである。また、図７及び図８のハイブリッド具体例は、図２乃至図６の具体例のネイティブＸＭＬプリンタシステムと既知のＺＰＬプリンタとの組み合わせではないことに着目すべきである。ネイティブＸＭＬモードとＺＰＬモードとの間で単に切り替わる"２イン１（two-in-one）"プリンタではない。

図７及び図８のＸＭＬプリンタシステムは、ＸＳＬテンプレートに組み込まれたＸＳＬフォーマット要素とともにラベルを定義してレイアウトするためにＸＳＬＴが用いられる図２乃至図６のネイティブＸＭＬプリンタシステムとは異なる。図２乃至図６のネイティブＸＭＬプリンタシステムの具体例におけるラベルのレイアウト及びフォーマットを扱うために、ネイティブＸＭＬプリンタ具体例において上述したように、多くの状況において、会社（又はベンダ）は、ＸＳＬフォーマットオブジェクトを用いて、ラベルレイアウトを用意して定義しなければならず、さらにＸＳＬスタイルシート及びＸＳＬスキーマを用意しなければならない。ＸＳＬフォーマットオブジェクト等（すなわち、ＸＳＬスタイルシート及びスキーマ）をまず第１に用いて、ビジネスエンティティのＥＲＰシステム８８がよく形成されたＸＭＬデータを送信することができた場合には、ビジネスエンティティが完全に互換性を有するＸＭＬＥＲＰシステムに対する完全な切り替えを既に行ったことを示すであろうＺＰＬテンプレートを用いる必要はなく、したがって、ＺＰＬの任意の形式の必要性は除去される。

しかしながら、いくつかの会社は、そのシステムの"純粋なＸＭＬ（pure XML）"へのそのような"完全な変換"への投資を行う準備又は意志がないかもしれない。そのような会社は、印刷されるべき彼らのラベルについてのより古いＺＰＬテンプレートにおけるかなり大きな投資を行っているかもしれないためである。多くの会社は、ビジネスプロセスからビジネスプロセスへとＸＭＬデータが容易に渡されることを可能とするためのインフラストラクチャを構築している。ＸＭＬ互換性を有するフォーマットにおけるそのようなデータの送信が、業界標準となっているためである。多くの会社及び業界は、全体として、データについてＸＭＬフォーマットを使用する方向に移動しているが、そのような会社は、完全に互換性を有するＸＭＬフォーマットへの切り替えを単に行うために、彼らのテンプレートデータベースインフラストラクチャにおける彼らの投資を廃棄したいと思わないかもしれない。

したがって、図７及び図８のハイブリッドＸＭＬプリンタ具体例は、ＸＭＬフォーマットにおけるデータとともに既存のＺＰＬテンプレートの使用を可能とする。ＥＲＰシステム８８は、最も経済的理由のために、よく形成されたＸＭＬへの"完全な（complete）"切り替えがまだ行われていないことから、既存のＺＰＬテンプレートを使用し続けなくてもよい。したがって、ＸＳＬスタイルシート、スキーマ、及びフォーマットオブジェクトは、ＥＲＰサイトでまだ実装されておらず、ハイブリッドＸＭＬプリンタシステムは、そのような環境でコスト効率のよい解決を提供する。

ここで、図７を参照するとともに、"コードセグメント５−−ＺＰＬダウンロード可能テンプレート（code segment 5 -- a ZPL downloadable template）"と題した直後に示すコードセグメント５を参照する。コードセグメント５は、実際のバーコードラベルの印刷に先だってハイブリッドＸＭＬプリンタシステム３００に対して送信されてもよく、また、将来の印刷ジョブのためにプリンタシステムのメモリに保存されてもよいＺＰＬフォーマットテンプレートの特定の例を示すものである。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

コードセグメント５−−ＺＰＬダウンロード可能テンプレート
１ ^XA
^DFE:SHIPLABL.ZPL^FS
^MCY
^LRN^FWN^CFD,24^LH0,0
５ ^CI0^PR2^MNY^MTT^MMT^MD0^JJ0,0^PON^PMN
^LT0
^A0N,58,58^FO188,169^CI0^FN999^FDname^FS
^A0N,58,58^FO188,244^CI0^FN998^FDaddress^FS
^A0N,58,58^FO188,319^CI0^FN997^FDcity^FS
１０ ^A0N,58,58^FO657,319^CI0^FN996^FDstate^FS
^A0N,58,58^FO188,394^CI0^FN995^FDzip^FS
^BY4^FO188,488^BZN,35,N^FN995^FDzip^FS
^PQ1,0,1,Y
１４ ^XZ

従来から知られているように、第１行目及び第１４行目に示されるコマンド（^XA，^XZ）は、ＺＰＬ言語で指定されるように、テンプレートの開始及び終了を定義する。第２行目は、ハイブリッドプリンタシステム３００にダウンロードされたフォーマットテンプレートが、"E:SHIPLABL.ZPL"によって定義された位置で当該ハイブリッドプリンタのメモリに格納されることを示す。ここで、"E:"は、例えばディスクドライブである記憶装置の識別子を表す。しかしながら、いかなる適切な記憶装置が用いられてもよい。このコマンドの包含は、このフォーマットテンプレートが保存されることになっていることを示す。第３行目〜第６行目は、ＺＰＬプログラミング言語によって提供される様々なプリンタセットアップ及び初期化コマンドのうちのいくつかを表す。

ここで、第７行目を参照すると、パラメータ"N"と結び付いた"＾A0"コマンドは、テキストフィールドがフォント番号０を用いて、且つ標準（normal；"N"）の方向（orientation）（すなわち、フォントは回転しない）で生成されることになっていることを意味する。ここで、"58, 58"は、印刷されるテキストの高さ及び幅（ドットで）を表す。ＺＰＬ言語で提供されるように、コマンド"＾FO188,169"は、テキストが座標１８８，１６９（すなわち、ラベルの開始から横方向に１８８ドット及び下方向に１６９ドット）に位置するように、フィールド原点を定義する。

コマンド"＾FN999"（"999"のパラメータを備えたＦＮコマンド）は、後でプリンタにダウンロードされる可変情報を含むであろう可変フィールドを定義する。その点で、これは、標準のＺＰＬにおけるものとは多少異なる。標準のＺＰＬにおいて、テンプレートにおける"＾FN"コマンドが受信された場合には、データは、コマンドとともに供給されない。テンプレートがその後再度呼び出される場合には、その可変データの位置を指定する後の"＾FN"コマンドは、データそのものに後続して送られるためである。しかしながら、このハイブリッドの具体例において、ある"関係（association）"データは、"＾FD"データフィールドコマンドによって指示されたときに、直ちに"＾FN"コマンドに続いて提供される。この特定の例において、"＾FN"コマンドに直ちに続くデータは、"＾FD"データフィールドコマンドによって先行されるが、"名前（name）"として示され、後でＥＲＰ又はウェアハウスシステムから送られたＸＭＬデータと結び付けられるデータである。したがって、コードセグメント５において示されるテンプレートがハイブリッドＸＭＬプリンタシステム３００によって受信された場合には、それは、当該プリンタのメモリに格納され、さらに、"名前（name）"とフィールド"999"との間の"関係（association）"は、格納される。

同様に、第８行目で、"住所（address）"とフィールド９９８との間の関係が格納され、第９行目で、"都市（city）"とフィールド９９７との間の関係が格納される、等である。例えば、"名前（name）"、"住所（address）"、及び"都市（city）"等によって表されるフィールドは、ＥＲＰシステム８８によるＸＭＬデータとして送られる実際のデータではないことに着目すべきである。より正確にいえば、"名前（name）"、"住所（address）"、及び"都市（city）"は、後でＥＲＰシステムによってフィールド位置又は識別子、すなわち、"999"、"998"、"997"とともにそれぞれ送られるデータを関連させる"タグ（tags）"又は"関係（associations）"である。

ここで、第１２行目を参照すると、"＾BY"コマンドは、それに続くバーコードコマンドについてのデフォルトパラメータを定義する。この場合、パラメータ４は、狭いバーの幅が４ドットであることを定義する。"＾FO"コマンドは、印刷されるバーコードが座標１８８，４８８に配置されることを定義する。"＾BZ"コマンドは、標準の方向（orientation）であり（パラメータＮ）、３５ドットの高さであり（パラメータ３５）、及び人間の判読可能な解釈行がない（パラメータＮ）、ポストネットタイプのバーコードフォーマットであるバーコードを定義する。さらに、パラメータ９９５を備えた"FN"コマンドは、"郵便番号（zip）"が実際の印刷されたバーコードを生成するためにダウンロードされるＸＭＬデータの名前であることをさらに指定する"郵便番号（zip）"の属性を有するデータコマンド"＾FD"によって定義された、ダウンロードされるＸＭＬデータの名前と"995"として識別されたラベルフィールドとの間の関係を指定する。図９に示すように、印刷される実際のバーコードは、郵便番号３０４である。

勿論、テキストフィールドは、図９に示すように、バーコード３０４そのもの上にもバーコードラベル３０５上にも印刷される。そのようなフィールドは、例えば、名前３０６、住所３０８、都市３１０、州３１２、及びテキスト郵便番号３１４を含んでもよい。

したがって、この具体例において、コードセグメント５において示されるテンプレートは、ハイブリッドＸＭＬプリンタシステム３００に格納され、実際の"ワーク（work）"は、実行されない（すなわち、ラベルは、まだ印刷されない。）。要約すると、上述したように、第７行目〜第１１行目は、テキストフィールドを定義し、第１２行目は、他のパラメータに加えて、後でＥＲＰシステム８８から送られた実際のＸＭＬデータと相互に関連させられるであろう関係とともに定義されるバーコードを定義する。コードセグメント５のテンプレートは、どのフィールドが無変化（static）であり、どのフィールドが可変（variable）であるかを定義してもよい。可変フィールドは、（^FDコマンドに格納される）可変名を有し、可変名は、印刷されたラベルに対応する後でダウンロードされるデータと後で相互に関連又は"関係（associated）"させられてもよい。

したがって、図７及び図８のハイブリッド具体例において、"＾FD"コマンド（すなわち、"名前（name）"によって続けられる）は、バーコードラベル上に印刷される実際のデータではなく、結果としてテンプレートのダウンロードに続く実際のＸＭＬデータにおいて送られる可変名を決定する。

上述したコードセグメント５のフォーマットテンプレートがオペレーションにおいてどのように用いられるのかをみるために、"コードセグメント６−−ＺＰＬテンプレートとともに使用するダウンロードされたＸＭＬデータ（code segment 6 -- downloaded XML data for use with a ZPL template）"と題したコードセグメント６が直後に示される。行番号は、例示の目的のためにのみ挿入されており、コードの一部ではない。

コードセグメント６−−ＺＰＬテンプレートとともに使用するダウンロードされたＸＭＬデータ
１＜?xml version="1.0" encoding="UTF-8"?＞
＜!DOCTYPE labels SYSTEM "label.dtd"＞
＜labels _FORMAT="E:SHIPLABL.ZPL" _QUANTITY="1" _PRINTERNAME="Printer
1" _JOBNAME="LBL101"＞
５＜label＞
＜variable name="name"＞Albert Einstein＜/variable＞
＜variable name="address"＞1234 Relative Way＜/variable＞
＜variable name="city"＞Princeton＜/variable＞
＜variable name="state"＞NJ＜/variable＞
１０＜variable name="zip"＞08540＜/variable＞
＜/label＞
＜label＞
＜variable name="name"＞Steven Hawking＜/variable＞
＜variable name="address"＞5678 Black Hole Drive＜/variable＞
１５＜variable name="city"＞Los Angeles＜/variable＞
＜variable name="state"＜CA＜/variable＞
＜variable name="zip"＞90007＜/variable＞
＜/label＞
＜label＞
２０＜variable name="name"＞Richard Feynman＜/variable＞
＜variable name="address"＞90 Quantum Circle＜/variable＞
＜variable name="city"＞New York＜/variable＞
＜variable name="state"＞NY＜/variable＞
＜variable name="zip"＞10044＜/variable＞
２５＜/label＞
＜/labels＞

コードセグメント６は、コードセグメント５のフォーマットテンプレートがハイブリッドＸＭＬプリンタシステムに最初にダウンロードされた後ではあるが、ＥＲＰシステム８８又はウェアハウス管理システムがハイブリッドＸＭＬプリンタシステム３００に対して送る実際のＸＭＬデータストリームを表す。コードセグメント５，６の特定の例において、例えば、用いられてもよいウェアハウス管理システムは、オラクルウェアハウス管理システム（"オラクルシステム（Oracle system）"又は"オラクルＷＭＳ（Oracle WMS）"）である。勿論、オラクル及びＳＡＰ等のようないかなるビジネスシステムが用いられてもよい。この特定の例において、オラクルシステムは、そのデータベースからデータを収集し、プリンタに対する送信のために特定のＸＭＬフォーマットでデータをフォーマットする。この特定の例は、オラクルシステムを用いることから、コードセグメント６のテンプレートは、オラクルＸＭＬ意味論を用いる。

その点で、オラクルウェアハウス管理システムによって用いられる特定のＸＭＬ意味論は、従来から知られているように、"label.dtd"として識別される"DTD"又は文書タイプ定義によってコードセグメント６の第２行目において定義される。また、従来から知られているように、ＥＲＰシステム８８又はオラクルシステムは、ＸＭＬデータが印刷されることになっているフォーマットを指定する能力を有する。背景の方法により、この能力は、オラクルシステム及び他のＥＲＰシステムにもとは組み込まれてもよい。そのようなシステムは、カスタム"ミドルウェア（middleware）"ソフトウェアシステムに対してインターフェースするためにもともと設計され、オラクル又はＥＲＰシステムと使用中の特定のバーコードプリンタとの間のフォーマット変換を扱ったためである。本ハイブリッドプリンタは、そのような"ミドルウェア（middleware）"ソフトウェアシステムの必要性を除去する。

しかしながら、オラクルシステムによって送信されたＸＭＬデータは、コードセグメント６の第３行目で、"_FORMAT"と呼ばれる属性を有する"ラベル（labels）"と呼ばれるＸＭＬ要素があることを指定する。この属性は、用いる特定のフォーマットテンプレートを指定する。この特定の例において、送信されたＸＭＬデータとともに用いるフォーマットテンプレートは、"E:SHIPLABL.ZPL"として識別され、コードセグメント５において示されるように、以前にハイブリッドＸＭＬプリンタシステム３００に格納されたフォーマットテンプレートであり、ＺＰＬに基づいたフォーマットテンプレートである。したがって、以前にハイブリッドＸＭＬプリンタシステム３００のメモリにダウンロードされて格納されたフォーマットテンプレートは、"E:SHIPLABL.ZPL"によって指定された位置から再度呼び出されてもよい。

第３行目はまた、"_QUANTITY"、"_PRINTERNAME"、及び"_JOBNAME"のような"ラベル（labels）"要素のいくつかの追加の属性を含む。属性"_QUANTITY"は、印刷するバーコードラベルの数を指定する。一方、属性"_PRINTERNAME"及び"_JOBNAME"は、ハイブリッドＸＭＬプリンタシステム３００によって必要とされないレガシーフィールドであるが、上述したように、そのようなデータは、ミドルウェアソフトウェアに対してインターフェースするためにもともと生成されたことから、それにもかかわらずオラクルデータに含まれる。

コードセグメント６は、第５行目〜第１１行目、第１２行目第１８行目、及び第１９行目第２５行目にそれぞれ示されるように、"ラベル（label）"データの３つのグループを含む。両方のコードセグメントが、"アルベルト・アインシュタイン（Albert Einstein）"、"スティーブン・ホーキング（Steven Hawking）"、及び"リチャード・ファインマン（Richard Feynman）"にそれぞれ言及することから、"ラベル（label）"データの３つのグループは、コードセグメント１、すなわち、第８行目〜第１４行目、第１５行目〜第２１行目、及び第２２行目〜第２８行目にそれぞれ類似しているようにみえ、また、住所、都市、州、及び郵便番号データについてのフィールドに関連していることに着目すべきである。したがって、コードセグメント６において示されるデータは、印刷される３つの個々のラベルに対応する。しかしながら、印刷される３つのラベルのそれぞれについては、全ての
受取人情報がテキストとして印刷されるが、郵便番号フィールドのみが実際のバーコードとして印刷されることに着目すべきである。これは、コードセグメント５の第１２行目のテンプレートにおいて定義された"＾BZ"コマンドのためである。

コードセグメント５，６を参照すると、その後、コードセグメント６において示されるオラクルシステムによって送信されたデータは、コードセグメント５において示される対応するフォーマットテンプレートに関係している。例えば、コードセグメント６の第６行目において、"名前（name）"の可変名は、実際のＸＭＬテキストデータである"アルベルト・アインシュタイン（Albert Einstein）"に対応する。コードセグメント５の第７行目に示されるように、以前に保存されたコードセグメント５のテンプレートを用いて、関係（association）は、"名前（name）"（その内容は、"アルベルト・アインシュタイン（Albert Einstein）"である）と、フィールド番号"999"との間に作られる。そして、ＸＭＬデータ"アルベルト・アインシュタイン（Albert Einstein）"は、フィールド番号９９９によって定義されたメモリに保存される。

同様に、ＸＭＬデータ"リレイティブウェイ１２３４（1234 Relative Way）"は、フィールド番号９９８によって定義されたメモリに保存され、ＸＭＬデータ"プリンストン（Princeton）"は、フィールド番号９９７によって定義されたメモリに保存され、ＸＭＬデータ"ニュージャージー（NJ）"は、フィールド番号９９６によって定義されたメモリに保存される、等である。一旦ＸＭＬデータ入力ストリームに含まれていた全てのデータが対応するテンプレートに関係していてメモリにロードされると、ラベルは印刷される。

ここで、図７及び図８を参照すると、図７は、ハイブリッドＸＭＬプリンタシステム３００の特定の具体例のハイレベルの機能ブロック図を示し、一方、図８は、ハイブリッドＸＭＬプリンタシステムの特定の具体例のハイレベルのソフトウェアブロック図及びデータフロー図を示す。ネイティブＸＭＬプリンタシステムに関して上述したように、ハイブリッドＸＭＬプリンタシステム３００は、エンタープライズ・リソース・プランニング（ＥＲＰ）・システム８８からデータを受信する。データは、ＸＭＬデータ及び／又はＺＰＬテンプレートデータのようなＸＭＬコンポーネント及びＺＰＬコンポーネントの両方を含んでもよい。

図７のハイレベルのブロックは、一種のＸＭＬプロセッサであるＳＡＸプロセッサ３２０の使用を示す。背景の方法により、ＳＡＸ（Simple API for XML）プロセッサは、図２乃至図６のネイティブＸＭＬプリンタシステムに関して上述したＸＭＬプロセッサによって用いられるＤＯＭ（Document Object Model）処理モデルを用いない。

上述したように、ＤＯＭに基づくＸＭＬプロセッサは、従来から知られているように、その処理ステップを実行するために、メモリにおいてノードツリーを生成する。これは、図２乃至図６の具体例に関して上述したように、ＸＳＬタイプ処理を実行する場合には必要である。したがって、全てのデータはメモリに格納され、これにより、大量のメモリを占めてもよい。しかしながら、ＳＡＸプロセッサは、ＸＭＬシンタックス及びデータストリームを解釈し、また、従来から知られているように、メモリにおいてノードツリーを構築するのではなく、イベントハンドラによって扱われる"イベント（events）"を生成する。ＳＡＸプロセッサは、非常に効率的にメモリを使用し、大量のＸＭＬデータを処理する場合には望ましい。

しかしながら、図７及び図８のこの代替具体例において、メモリにおけるノードツリーに基づいた処理が要求されないことから、ＸＳＬタイプ処理は、むしろ実行されない。したがって、ＤＯＭに厳密に基づくＸＭＬプロセッサを用いるのではなく、図７において示されるように、ＳＡＸプロセッサが用いられてもよい。用語"ＳＡＸ"は、ＸＭＬ言語のデータ及びシンタックスを扱う方法に関する仕様を単に指す。例えば、この具体例において用いられてもよい商業上利用可能なＸＭＬプロセッサは、タイのオープンソースソフトウェアセンタ社（Thai Open Source Software Center, Ltd.）製のＸＭＬプロセッサである"Ｅｘｐａｔ"である。ＸＭＬプロセッサのこの特定のモデルは、ＤＯＭに基づくＸＭＬプロセッサ又はＤＯＭに基づかないＳＡＸプロセッサの両方としての機能に対して能力を有するが、この具体例の目的のために、プロセッサは、ＤＯＭに基づかないＸＭＬプロセッサとして形成されるのが望ましく、これにより、ＳＡＸプロセッサと称される。

図７に示すように、ＳＡＸプロセッサ３２０に加えて、ＺＰＬプロセッサ３２２も示される。そして、ＳＡＸプロセッサ３２０及びＺＰＬプロセッサ３２２からのデータパスは、可変データ統合（Variable Data Integration）３２８とラベル付けされたブロックまで経路が定められる。可変データ統合ブロック３２８は、コードセグメント５のＺＰＬテンプレートに関して上述したように、ＥＲＰシステム８８から受信されたＸＭＬデータを結合するとともに、ＺＰＬテンプレートによって以前に定義されたフィールドにデータを適用する又は"関係させる（associates）"。本質的に、このステップにおいて、例えば名前"アルベルト・アインシュタイン（Albert Einstein）"といった実際のＸＭＬデータは、コードセグメント５のテンプレートの９９９等によって定義されたその関連する位置に保存される。

続いて、データは、ビットマップ／バーコードレンダリングブロック３３０によってレンダリングされ、その処理は、既知の商業上利用可能なＺＰＬプリンタにおいて用いられる既知のＺＰＬビットマップレンダリングと同様である。例えば、イリノイ州ヴァーノンヒルズのゼブラ・テクノロジーズ社製である以下の既知のＺＰＬプリンタは、以下のようにＺＰＬビットマップ／バーコード処理を実行することができるソフトウェア、ハードウェア、及び／又はファームウェアを含んでもよい：ゼブラ社製のゼブラモデルＸｉＩＩＩ＋、９０ＸｉＩＩＩ、９６ＸｉＩＩＩ、１４０ＸｉＩＩＩ、１７０ＸｉＩＩＩ、２２０ＸｉＩＩＩ、モデルＺ４Ｍ，Ｚ６Ｍ，１０５ＳＬ、及び任意のモデルＸｉシリーズ・バーコードプリンタ。ビットマップ／バーコードレンダリングブロック３３０は、ネイティブＸＭＬプリンタシステム具体例において要求されるいかなるＸＳＬＦＯ処理を用いることなく実行されるのが望ましく、ＸＳＬＴスタイルシート又はスキーマは、用いられないことに着目すべきである。

属性としてのＸＭＬデータにおいてバーコードパラメータが指定されないことを除くのが望ましく、フォーマットテンプレートにおいてＺＰＬコマンドパラメータによって指定されるのが望ましいものの、上述したように、バーコードは、ネイティブＸＭＬプリンタ具体例についてレンダリングされる。例えば、ＺＰＬコマンド"＾BY2，2,100"は、リニアバーコードについて、狭いバーの幅が２ドットであり、狭いバーの幅に対する広いバーの幅の比率が２であり、バーの高さが１００ドットであることを指定する。

ビットマップがレンダリングされた後、それは、図１においてまた示されるプリンタドライバ５４まで経路が定められる。プリンタドライバ５４は、関連する処理装置の物理的な位置に応じて、コンピュータシステム１２における処理装置又は処理装置６０（図１）のいずれかによってその機能が実行されてもよい上述したコンポーネントの例である。その上、単一の処理装置は、十分に強力である場合には、ハイブリッドＸＭＬプリンタシステム３００についての全ての機能を担ってもよい。

ここで、図１、図７及び図８を参照すると、図８は、ハイレベルのソフトウェアブロック図及びデータフロー図の組み合わせの特定の具体例を示す。後述するソフトウェアは、図１のコンピュータシステム１２のプロセッサ２８によって実行されてもよい。その上、プロセッサ２８は、コンピュータシステム１２及びプリンタシステム５０の両方に共通の機能を実行してもよい。１つ以上のプロセッサがあってもよく、それらは協調して機能してもよく、又は別個に機能してもよい。処理又は処理機能が、コンピュータシステムによって若しくはコンピュータシステムで、又はプリンタシステムによって若しくはプリンタシステムで実行されたとしても、それは、この発明の範囲についての本質ではない。

後述するように、図８において示される処理ステップによってマルチプル"パス（passes）"がＳＡＸプロセッサ３２０の管理のもとで生じてもよい。しかしながら、そのようなマルチプル"パス（passes）"は、必ずしも線形でなく、したがって、図８における特定の線又は矢印によって示された正確なパスは、必ずしも示されていないかもしれない。図８に示される正確な開始及び終了ポイントを有しなくてもよい反復プロセスが記述される。より正確にいえば、パスによって生成された行為又は結果が示されてもよく、したがって、"代替パス（alternative path）"が、図８におけるＳＡＸプロセッサ３２０に処理制御を返す断続線において示されてもよい。これは、パスが反復してもよく、処理がその終了に到着する前にＳＡＸプロセッサ３２０が何度もループ又は反復してもよいことを示す略記方法である。

図示の目的のためにのみ、図８において示される処理による第１の"パス（pass）"において、印刷される実際のデータがまだ送られない場合には、ＺＰＬテンプレートは、まずハイブリッドＸＭＬプリンタシステム３００に対して送られる。第２の"パス（pass）"において、さらに後述するように、印刷されるバーコードラベルを表すＸＭＬデータは、以前に保存されたＺＰＬテンプレートにしたがって印刷されるために、プリンタシステムに対して送られる。

図８において示されるように、データ入力ストリーム３４０は、上述したように、ＥＲＰシステム８８から受信され、ＸＭＬデータ及び／又はＺＰＬテンプレートデータを含んでもよい。ＳＡＸ処理ブロック３２０は、最初にデータ入力ストリーム３４０を受信して解析する。ＳＡＸプロセッサがＳＡＸモードで作動するＸＭＬプロセッサであることから、ＳＡＸ処理ブロック３２０は、ＸＭＬプロセッサによって現実に実行されることに着目すべきである。したがって、ＸＭＬプロセッサ又はＸＭＬ処理ブロックのフレーズは、ＳＡＸプロセッサ又はＳＡＸ処理ブロックのフレーズと交換されてもよい。しかしながら、上述したように、ＸＭＬプロセッサは、ＳＡＸモードで作動するのが望ましく、これにより、ＳＡＸプロセッサ３２０と称される。

まず、ＳＡＸ処理ブロック３２０は、データ入力ストリームに標準のＸＭＬシンタックス規則を適用することにより、データ入力ストリーム３４０がよく形成されたＸＭＬデータであるか否かを決定する。いくつかのハードウェアを示す図７及びデータフローを示す図８について、図８のＳＡＸ処理ブロック３２０は、本質的に、図７のＳＡＸプロセッサと同様であることに着目すべきである。ＳＡＸプロセッサ及びＳＡＸ処理ブロックの用語は、ここに交換可能に用いられるであろう。

データ入力ストリームがＸＭＬシンタックスに合致しないことをＳＡＸ処理ブロック３２０が決定した場合には、データ入力ストリームは、ＺＰＬに基づいているものと仮定される。したがって、ＳＡＸ処理ブロック３２０は、データが入力ストリーム３４０をさらなる処理のためにＺＰＬ処理ブロック３２２まで経路を定める。いくつかのハードウェアを示す図７及びデータフローを示す図８について、図８のＺＰＬ処理ブロック３２２は、本質的に、図７のＺＰＬプロセッサと同様であることに着目すべきである。ＺＰＬプロセッサ及びＺＰＬ処理ブロックの用語は、ここに交換可能に用いられるであろう。

そして、ＺＰＬ処理ブロック３２２は、ＺＰＬフォーマットテンプレートを表すデータ入力ストリーム３４０を処理又は解析する。望ましくは、ＺＰＬ処理ブロック３２２は、フォーマットテンプレートの処理を開始させる"ラベルの開始（beginning of label）"コマンド（^XA）を受信する。フォーマットテンプレートは、コードセグメント５において示される。

様々なＺＰＬコマンドは、処理を管理するとともに、ラベルのフィールドを定義し、本質的に、印刷されるデータを確立して定義する。プリンタ制御及び他のコマンドは、処理のこの段階で受信されてもよい。全てのフォーマットテンプレートがダウンロードされた場合には、ＺＰＬ処理ブロック３２２は、フォーマットテンプレートを保存させる"ラベルの終了（end of label）"コマンド（＾XZ）に遭遇する。対応する識別子"E:SHIPLABL.ZPL"（コードセグメント５の第２行目に示される）を備えた＾DFコマンドは、フォーマットテンプレートがプリンタシステムにおける"E:"デバイス上にファイル名が"shiplabl.zpl"とされて内部的に保存されるのが望ましいことをＺＰＬ処理ブロック３２２に示す。勿論、フォーマットテンプレートをプリンタシステムにおいて内部的に保存する必要はなく、ネットワークに接続されたサーバ又は通信ネットワークを介してアクセス可能な遠隔位置のような任意の記憶位置に保存されてもよい。

＾DF（ダウンロードフォーマット）ＺＰＬコマンドは、直ちに印刷されるのではなく格納される部分であるラベルフォーマットを示す。全てのテンプレートデータが受信されたことを示す＾XZに遭遇した場合には、現実に保存は行われる。

また、図８において、ボックスを完成する垂線なしで"ＺＰＬラベルフォーマット（ZPL label formats）"（３５２）とラベル付けされたブロックは、データ格納部のための図中のシンボルであることに着目すべきである。これは、入力ストリームからのテンプレートデータがデータ格納部に格納されることを示す。データ格納部３５２から出ている線は、ある程度の後に、追加の処理のために当該データ格納部からデータが検索されることを示す。データフローパスは、ブロック３６０から、格納部、ブロック３５６まであるが、これは、リニアフローではない実際の"制御フロー（control flow）"を表していない。

"ＺＰＬラベルフォーマット再呼び出し（recall ZPL label format）"３５６とラベル付けされたブロックは、上述したように、"ＺＰＬラベルフォーマット保存（save ZPL label format）"３６０とラベル付けされたブロックに接続されて示され、処理は、リニアでなくてもよく、したがって、データフローは、"ＺＰＬラベルフォーマット保存（save ZPL label format）"ブロック３６０から"ＺＰＬラベルフォーマット再呼び出し（recall ZPL label format）"ブロック３５６まで、必ずしも継続又は進まなくてもよい。より正確にいえば、上述したように、全てのプロセスは反復し、この最初の"パス（pass）"において、ブロック３６０において示されるように、ＺＰＬラベルフォーマットが保存された後、断続線３７０によって示されるように、入力データストリームの制御は、継続される処理のためにＳＡＸ処理ブロック３２０に戻ってもよい。処理されるデータ入力ストリーム３４０に追加データがない場合には、処理は、追加のダウンロードされたデータを終了して待機する。

図７及び図８において示される処理による第２の"パス（pass）"において、ＥＲＰシステム８８は、以前にダウンロードされたＺＰＬテンプレートにしたがってハイブリッドＸＭＬプリンタシステム３００によって処理される実際のＸＭＬデータを送信してもよい。例えば、ＳＡＸ処理ブロック３２０は、ラベルデータが続くことを指定してもよいよく形成されたＸＭＬデータを受信してもよい。実際のデータを処理するために、"ＺＰＬラベルフォーマット再呼び出し（recall ZPL label format）"３５６とラベル付けされたブロックにおいて示されるように、格納されたＺＰＬフォーマットは、再度呼び出され、その結果、再度呼び出されたフォーマットテンプレートは、入力されるＸＭＬデータストリームとともに用いられてもよい。

ＳＡＸ処理ブロック３２０は、ＸＭＬシンタックスを処理し、また、データ入力ストリーム３４０によって定義された様々な要素及び属性を決定する。"_FORMAT"属性を受信するこの具体例において、データ入力ストリーム３４０は、一時的に中断され、また、入力データは、プリンタシステム３００に格納されたフォーマットテンプレートから到達する。したがって、フォーマットテンプレートに組み込まれたＺＰＬコマンドは、ＺＰＬ処理ブロック３２２によって解釈される。一旦フォーマットテンプレートにおけるコマンドが解釈されると、データ入力ストリーム３４０は、再度、ＸＭＬデータを処理し続けるＳＡＸ処理ブロック３２０に到達する。

上述したように、様々な"イベント（events）"は、ＳＡＸプロセッサ３２０の制御のもとで、処理による追加のパスによって開始されてもよい。例えば、フォーマットテンプレートにおける可変フィールドが、受信された対応する又は"関係する（associated）"ＸＭＬデータが構成されるように、"可変データＳＡＸイベント（variable data SAX event）"３７６は、開始されてもよい。これは、"ＸＭＬ変数とＺＰＬラベルフォーマット変数との結び付け（Match XML variable with ZPL label format variable）"３８０とラベル付けされたブロックによって示される。本質的に、ＸＭＬデータ入力ストリーム３４０の変数は、フォーマットテンプレートにおけるフィールドに関係する。例えば、このステップにおいて、コードセグメント６において示される実際のＸＭＬデータ"アルベルト・アインシュタイン（Albert Einstein）"（図９の３０６）のようなＸＭＬ変数は、コードセグメント５のＺＰＬテンプレートにおけるラベル変数"名前（name）"のようなＺＰＬラベルフォーマット変数と結び付けられる。

ＳＡＸプロセッサ３２０は、上述したタスクを扱うために、"開始ラベルＳＡＸイベント（begin label SAX event）"３８４及び"他のＳＡＸイベント（other SAX events）"３８８のようなさらなるイベントを開始してもよい。ＳＡＸプロセッサ３２０の制御のもとでの図８の処理によるこのパス又は他のパスは、"他のＳＡＸイベント（other SAX events）"の生成を引き起こしてもよく、"プロセスイベント（Process event）"３９０と称されるブロックによって処理されてもよい。例えば、そのような"他の"イベントは、"プリンタ速度設定イベント（set printer speed event）"、"印刷ラベル量設定イベント（set quantity of labels to print event）"、"媒体選択イベント（select media event）"、"使用リボン設定イベント（select ribbon to use event）"、"紙選択イベント（choose paper event）"、"３００ｄｐｉプリンタ使用イベント（use 300 dpi printer event）"、"６００ｄｐｉプリンタ使用イベント（use 600 dpi printer event）"、及び"可変データイベント（variable data event）"等を含んでもよい。

そのようなイベントの数は、事実上無制限であり、ハードウェアプリンタシステムのタイプ、構成、及び能力によって管理される。本質的に、プリンタの全ての様相及び機能は、データ入力ストリーム３４０において送られたコードの使用によって制御されてもよい。これはまた、ＸＭＬデータストリームによって記述されたラベルを印刷する能力があるか否か又は印刷するように形成されているか否か、それができない場合には任意にエラー情報を返す能力があるか否か又は返すように形成されているか否かについて、プリンタが決定することを可能とする。本質的に、オラクルベースのＸＭＬデータに対応するコードセグメント６においては、"他のコマンド（other commands）"の数にのみ制限がある（すなわち、両方とも第３行目に示される量（quantity）＝１及びプリンタ名（printer name）＝プリンタ１）ように示されるが、上述したように、プリンタにおいて制御されてもよい任意の機能又は特徴がＸＭＬ入力データストリームにおいて指定されてもよい。したがって、実際のＸＭＬ入力データとプリンタ制御コードとの間には密な拘束力があってもよい。

また、コマンドに応じてＳＡＸ処理ブロック３２０によって生成されたそのような"他の"コマンド及び対応する"他のイベント"は、オラクルシステム（the Oracle system）の部分又はオラクルシステムに特有ではないことに着目すべきであり、それは、これらのコマンドが何を行うか又はそれらがどのように用いられるかについてオラクルシステムが必ずしも"知っている"必要がないことを意味する。コマンド及び後の生成されたイベントが意味を呈するのは、そのようなダウンロードされたコマンドがＳＡＸ処理中に結び付けられる場合のみである。

"ラベル要素の終了（end of label element）"イベント（＜/label＞）が受信された場合には、ラベルは、完成し、そこで印刷されてもよい。そして、制御は、ラベルを印刷するＺＰＬフォーマットエンジン処理３９４まで経路が定められる。望ましくは、ＺＰＬフォーマットエンジン処理３９４の機能は、ビットマップ／バーコードレンダリングの機能を含む。これにより、ブロック３９４は、ＺＰＬフォーマットエンジンと称される。この組み合わされた機能は、テキスト、バーコード、及びラベル上の他のフィールドのそれぞれについてのビットマップを決定し、個々のビットマップを単一のラベルビットマップ３９６へと適切な回転及び拡大して統合し、媒体上での物理的なレンダリングのために印刷エンジン（又はプリンタドライバ５４（図１））に対して完成したラベルビットマップを送る。上述したように、ＺＰＬフォーマットエンジン処理３９４は、例えば、イリノイ州ヴァーノンヒルズ（Vernon Hills, Illinois）のゼブラ・テクノロジーズ社（Zebra Technologies Corporation）製のような様々な商業上利用可能なＺＰＬプリンタにおいてみつかるかもしれず、以下のプリンタモデルを含んでもよい：ＸｉＩＩＩ＋、９０ＸｉＩＩＩ、９６ＸｉＩＩＩ、１４０ＸｉＩＩＩ、１７０ＸｉＩＩＩ、２２０ＸｉＩＩＩ、モデルＺ４Ｍ，Ｚ６Ｍ，１０５ＳＬ、及び任意のモデルＸｉシリーズ・バーコードプリンタ。

ＺＰＬフォーマットエンジン処理３９４は、本質的に、印刷されるラベルに含まれていた全てのフィールドを決定し、各フィールドについて行われなければならないことを決定する。例えば、ＺＰＬフォーマットエンジン処理３９４は、コードセグメント６の第６行目に示されるデータ"アルベルト・アインシュタイン（Albert Einstein）"（図９の３０６）を含むフィールドが、フォント番号０を用いて、且つ標準（normal；"N"）の方向（orientation）で印刷され、また、コードセグメント５の第７行目によって示されるように、高さが５８ドットで且つ幅が５８ドットであり、また、フィールド原点座標１８８，１６９で開始することを決定してもよい。

したがって、ＺＰＬフォーマットエンジン処理３９４は、対応するＸＭＬデータとともにフォーマットテンプレートによって定義された全てのフィールドを検査し、本質的に、テキスト又はバーコードを表すラベル上でドット（又はビット）を生成する方法を決定する。バーコードフィールドは、リニアバーコードの水平及び垂直の大きさに、並びに２次元バーコードの拡大を説明するフィールドのために指定されたバーコード記号体系に基づいたフィールドパラメータに対して適切なビットマップ生成アルゴリズムを適用することにより、フォーマットされてレンダリングされる。

本発明にしたがうネイティブＸＭＬプリンタシステム及びハイブリッドＸＭＬプリンタシステムを含むＸＭＬプリンタシステムの特定の具体例は、本発明がなされて使用されてもよい方法を例示する目的のために記述された。本発明及びその様々な様相の他のバリエーションの実装及び変更は、当該技術の熟練者にとって明白であろうこと、並びに本発明は、上述した特定の具体例によって制限されないことは理解されるべきである。したがって、本発明は、ここに開示されて請求された基本的な根本原理の真情及び範囲内で任意又は全ての変更、バリエーション、又は等価物を包含するように熟考される。

図１は、本発明にしたがうプリンタシステムの特定の具体例のハイレベルのハードウェアブロック図である。図２は、プリンタシステムの特定の具体例のハイレベルのソフトウェアブロック図である。図３は、プリンタシステムの特定の具体例のハイレベルのソフトウェアブロック図及びデータフロー図の組み合わせである。図４は、ビットマップ／バーコードレンダリングエンジンの特定の具体例のハイレベルのソフトウェアブロック図である。図５は、図１乃至図４のプリンタシステムにしたがって製造されたバーコードラベルの特定の表現である。図６は、バーコードレンダリングサーバとして形成されたプリンタシステムの代替具体例の特定の例である。図７は、プリンタシステムの特定の代替具体例のハイレベルのソフトウェアブロック図である。図８は、プリンタシステムの特定の代替具体例のハイレベルのソフトウェアブロック図及びデータフロー図の組み合わせである。図９は、図７及び図８のプリンタシステムにしたがって製造されたバーコードラベルの特定の表現である。

Claims

拡張可能マークアップ言語（extensible markup language；ＸＭＬ）入力データストリームに基づいてバーコードラベルを印刷するように適応され、媒体制御システムと、印刷ヘッドアセンブリと、印刷ヘッドドライバとを有するプリンタ装置を含むＸＭＬプリンタシステムであって、
上記プリンタ装置に作用的に接続されたコンピュータシステムを備え、
上記コンピュータシステムは、さらに、
メモリサブシステムと、
ネットワークに作用的に接続された通信インターフェースと、
上記ＸＭＬ入力データストリームを受信して処理するとともに、スキーマリポジトリから上記ＸＭＬデータストリームにおいて識別されたスキーマを得るように形成され、得られた上記スキーマに基づいて上記ＸＭＬデータストリームを検証するＸＭＬプロセッサと、
スタイルシートリポジトリから上記ＸＭＬデータストリームにおいて識別されたスタイルシートを得るように形成され、得られた上記スタイルシートに基づいて、上記ＸＭＬ入力データストリームにおけるデータを変換済ＸＭＬデータに変換する拡張可能スタイルシート言語変換（extensible stylesheet language transformation；ＸＳＬＴ）プロセッサと、
上記スタイルシートに含まれていたＸＳＬＦＯ指示に基づいて、上記変換済ＸＭＬデータをフォーマット済ＸＭＬデータにフォーマットするように形成された拡張可能スタイルシート言語フォーマットオブジェクト（extensible stylesheet language formatting object；ＸＳＬＦＯ）プロセッサと、
上記フォーマット済ＸＭＬデータを受信して上記バーコードラベルのビットマップ表現を生成するように形成されたバーコードレンダリングサブシステムとを含むこと
を特徴とするＸＭＬプリンタシステム。
上記メモリサブシステムは、ＲＡＭ、ＲＯＭ、ハードディスク記憶装置、及びデータベースシステムからなるメモリコンポーネントのグループから選択されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記メモリサブシステムは、上記コンピュータシステムから遠隔され、ネットワークを介してアクセス可能であること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記メモリサブシステムは、上記コンピュータシステムに組み入れられること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記コンピュータシステムは、コンピュータ、マイクロプロセッサ、ＲＩＳＣプロセッサ、ＣＩＳＣプロセッサ、メインフレームコンピュータ、ワークステーション、単一チップコンピュータ、分散型プロセッサ、サーバ、コントローラ、マイクロコントローラ、離散ロジックコンピュータ、及びインターネットコンピュータからなるグループから選択されるプロセッサを含むこと
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記ＸＭＬスキーマ及び上記ＸＳＬＴスタイルシートは、ＸＭＬ文書であること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記コンピュータシステム及び上記プリンタ装置は、共通の囲いに収容されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記コンピュータシステム及び上記プリンタ装置は、別個の囲いに収容されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記コンピュータシステム及び上記プリンタ装置は、別個の囲いに収容され、ネットワークを介して互いに通信すること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
エンタープライズ・リソース・プランニング（ＥＲＰ）・システムは、上記バーコードラベルの印刷を開始するために、当該ＸＭＬプリンタシステムに対して上記ＸＭＬ入力データストリームを送ること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記エンタープライズ・リソース・プランニング・システムは、ウェアハウス管理システムであること
を特徴とする請求項１０記載のＸＭＬプリンタシステム。
上記エンタープライズ・リソース・プランニング・システムは、上記ネットワークを介して当該ＸＭＬプリンタシステムに接続されること
を特徴とする請求項１０記載のＸＭＬプリンタシステム。
上記ＸＭＬプロセッサは、上記ＸＭＬ入力データストリームが上記スキーマにしたがって成功裡に検証されない場合には、上記エンタープライズ・リソース・プランニング・システムに対してエラー表示を送信すること
を特徴とする請求項１０記載のＸＭＬプリンタシステム。
上記ネットワークは、ローカルエリアネットワーク、リモートネットワーク、専用ネットワーク、イーサネット（登録商標）、インターネット、公衆交換電話網（Public Switched Telephone Network；ＰＳＴＮ）、及びＰＯＴＳ（plain old telephone system）からなるネットワークのグループから選択されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記スタイルシートリポジトリは、複数のスタイルシートを含み、上記ネットワークを介して上記コンピュータシステムによってリモートアクセスされること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記スキーマリポジトリは、複数のスキーマを含み、上記ネットワークを介して上記コンピュータシステムによってリモートアクセスされること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記スタイルシートリポジトリにおけるスタイルシートの少なくとも１つ、及び上記スキーマリポジトリにおけるスキーマの少なくとも１つは、周期的に更新されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記スタイルシートリポジトリから得られたスタイルシートの少なくとも１つ、及び上記スキーマリポジトリから得られたスキーマの少なくとも１つは、それぞれのリポジトリからの検索後に、上記メモリサブシステムに一時的に格納されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記バーコードレンダリングサブシステムは、上記スタイルシートにおいて定義されたインストリーム外部オブジェクトを処理すること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記インストリーム外部オブジェクトは、バーコードタイプオブジェクトであること
を特徴とする請求項１９記載のＸＭＬプリンタシステム。
上記ＸＳＬＦＯプロセッサは、バーコードタイプのインストリーム外部オブジェクトを処理することができないこと
を特徴とする請求項２０記載のＸＭＬプリンタシステム。
上記プリンタ装置は、上記スタイルシートにおいて指定されたバーコードタイプに基づいたバーコードシンボルを生成するために用いられる少なくとも１つのアルゴリズムを含むこと
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記バーコードレンダリングサブシステムは、上記バーコードラベルの印刷を促進する上記印刷ヘッドドライバに対してビットマップを提供すること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
外部ソースは、バーコードラベルビットマップを生成するために、当該プリンタシステムに対してリクエストを送信すること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記外部ソースは、上記ネットワークを越えて上記リクエストを送信すること
を特徴とする請求項２４記載のＸＭＬプリンタシステム。
上記外部ソースは、当該プリンタシステムに対して上記ＸＭＬ入力データストリームを送信すること
を特徴とする請求項２４記載のＸＭＬプリンタシステム。
外部ソースは、バーコードラベルビットマップを生成するために、当該プリンタシステムに対してリクエストを送信し、
当該ＸＭＬプリンタシステムは、上記リクエストに応じて、請求項１にしたがって当該リクエストを処理するとともに、上記外部ソースに対してビットマップを送信すること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
上記コンピュータシステムは、バーコードラベルをレンダリングするために、上記ＸＭＬ入力データストリームを送信する外部ソースからリクエストを受信し、
上記バーコードレンダリングサブシステムによって生成されたビットマップは、上記外部ソースに対して送信されること
を特徴とする請求項１記載のＸＭＬプリンタシステム。
バーコードプリンタ装置において用いるＸＭＬ処理システムであって、
上記バーコードプリンタ装置に作用的に接続されたコンピュータシステムを備え、
上記コンピュータシステムは、さらに、
ＸＭＬ入力データストリームを受信して処理するとともに、スキーマリポジトリから上記ＸＭＬデータストリームにおいて識別されたスキーマを得るように形成され、得られた上記スキーマに基づいて上記ＸＭＬデータストリームを検証するＸＭＬプロセッサと、
スタイルシートリポジトリから上記ＸＭＬデータストリームにおいて識別されたスタイルシートを得るように形成され、得られた上記スタイルシートに基づいて、上記ＸＭＬ入力データストリームにおけるデータを変換済ＸＭＬデータに変換する拡張可能スタイルシート言語変換（extensible stylesheet language transformation；ＸＳＬＴ）プロセッサと、
上記スタイルシートに含まれていたＸＳＬＦＯ指示に基づいて、上記変換済ＸＭＬデータをフォーマット済ＸＭＬデータにフォーマットするように形成された拡張可能スタイルシート言語フォーマットオブジェクト（extensible stylesheet language formatting object；ＸＳＬＦＯ）プロセッサと、
上記フォーマット済ＸＭＬデータを受信して上記バーコードラベルのビットマップ表現を生成するように形成されたバーコードレンダリングサブシステムとを含むこと
を特徴とするＸＭＬ処理システム。
拡張可能マークアップ言語（extensible markup language；ＸＭＬ）入力データストリームに基づいてバーコードラベルを印刷するように適応され、媒体制御システムと、印刷ヘッドアセンブリと、印刷ヘッドドライバとを有するプリンタ装置を含むＸＭＬプリンタシステムにおいて上記バーコードラベルを生成する方法であって、
スキーマリポジトリから上記ＸＭＬデータストリームにおいて識別されたスキーマを得る工程と、
ＸＭＬプロセッサを用いて上記ＸＭＬ入力データストリームを処理する工程と、
得られた上記スキーマに基づいて上記ＸＭＬデータストリームを検証する工程と、
スタイルシートリポジトリから上記ＸＭＬデータストリームにおいて識別されたスタイルシートを得る工程と、
拡張可能スタイルシート言語変換（extensible stylesheet language transformation；ＸＳＬＴ）プロセッサを用いて、得られた上記スタイルシートに基づいて、上記ＸＭＬ入力データストリームにおけるデータを変換済ＸＭＬデータに変換する工程と、
拡張可能スタイルシート言語フォーマットオブジェクト（extensible stylesheet language formatting object；ＸＳＬＦＯ）プロセッサを用いて、上記スタイルシートに含まれていたＸＳＬＦＯ指示に基づいて、上記変換済ＸＭＬデータをフォーマット済ＸＭＬデータにフォーマットする工程と、
上記スタイルシートに定義されたバーコードタイプインストリーム外部オブジェクトを処理するバーコードレンダリングサブシステムを用いて、上記フォーマット済ＸＭＬデータに基づいて、上記バーコードラベルのビットマップ表現を生成する工程と、
上記バーコードラベルの印刷を促進する上記印刷ヘッドドライバに対してビットマップを送信する工程とを備えること
を特徴とする方法。
バーコードプリンタ装置において用いるＸＭＬ処理システムであって、
上記バーコードプリンタ装置に作用的に接続されたコンピュータシステムを備え、
上記コンピュータシステムは、さらに、
ＸＭＬ入力データストリームを受信して処理するとともに、スキーマリポジトリから上記ＸＭＬデータストリームにおいて識別されたスキーマを得るように形成され、得られた上記スキーマに基づいて上記ＸＭＬデータストリームを検証するＸＭＬプロセッサと、
上記ＸＭＬデータストリームにおいて識別されたスタイルシートを得るように形成され、得られた上記スタイルシートに基づいて、上記ＸＭＬ入力データストリームにおけるデータを変換済ＸＭＬデータに変換する拡張可能スタイルシート言語変換（extensible stylesheet language transformation；ＸＳＬＴ）プロセッサと、
上記スタイルシートに含まれていたＸＳＬＦＯ指示に基づいて、上記変換済ＸＭＬデータをフォーマット済ＸＭＬデータにフォーマットするように形成された拡張可能スタイルシート言語フォーマットオブジェクト（extensible stylesheet language formatting object；ＸＳＬＦＯ）プロセッサと、
上記フォーマット済ＸＭＬデータを受信して上記バーコードラベルのビットマップ表現を生成するように形成されたバーコードレンダリングサブシステムとを含むこと
を特徴とするＸＭＬ処理システム。
拡張可能マークアップ言語（extensible markup language；ＸＭＬ）入力データストリーム及びフォーマットテンプレートに基づいてバーコードラベルを印刷するように適応され、媒体制御システムと、印刷ヘッドアセンブリと、印刷ヘッドドライバとを有するプリンタ装置を含むＸＭＬプリンタシステムであって、
上記プリンタ装置に作用的に接続されたコンピュータシステムを備え、
上記コンピュータシステムは、さらに、
メモリサブシステムと、
上記ＸＭＬ入力データストリームを受信して処理するように形成されたＳＡＸプロセッサと、
上記フォーマットテンプレートを受信して処理するように形成されたＺＰＬプロセッサと、
上記ＸＭＬ入力データストリームに含まれていたＸＭＬデータと上記フォーマットテンプレートとの間の関係を発生させるように形成された可変データ統合器と、
上記フォーマットテンプレートによって管理されたフォーマットにしたがって関連するＸＭＬデータをフォーマットするように形成されたフォーマットエンジンと、
上記関連してフォーマットされたＸＭＬデータを受信して上記バーコードラベルのビットマップ表現を生成するように形成されたバーコードレンダリングエンジンとを含むこと
を特徴とするＸＭＬプリンタシステム。
上記ＳＡＸプロセッサは、上記フォーマットテンプレートに組み込まれたコマンドに基づいて複数のイベントを生成すること
を特徴とする請求項３２記載のＸＭＬプリンタシステム。
上記イベントは、プリンタ速度設定イベント、印刷ラベル量設定イベント、媒体選択イベント、使用リボン設定イベント、紙選択イベント、３００ｄｐｉプリンタ使用イベント、６００ｄｐｉプリンタ使用イベント、及び可変データイベントからなるグループから選択されること
を特徴とする請求項３３記載のＸＭＬプリンタシステム。
上記フォーマットテンプレートは、上記ＳＡＸプロセッサに対して送られ、後でダウンロードされたＸＭＬデータとともに用いるために保存されること
を特徴とする請求項３２記載のＸＭＬプリンタシステム。
上記フォーマットテンプレートは、ＺＰＬに基づいたフォーマットテンプレートであること
を特徴とする請求項３２記載のＸＭＬプリンタシステム。