| 項番 | コメント内容 | 回答 |
| 1 | 要素定義の中に半角カナを使用するという要素がありますが、XMLファイルをインターネット上で交換する場合に文字化けなどの問題は発生しないのでしょうか？ | １．XML形式のファイルに半角カナを使用できるかどうかということについては、Shift-JIS、UTF-8、EUC-JPなどのエンコーディング（文字の符号化の方式）を使用すれば可能です。 ただしUTF-8では、OSやアプリケーションによってはそのXMLファイルを解釈できず、文字化けを発生する場合があり、その場合はShift-jisに変換して使用すれば問題が解決する可能性があります。 ２．半角カナを含んだXMLファイルを交換する場合、メール本文または添付で送信した時に文字化けを発生する可能性が高いので、アーカイブ(lzh,zipなどを使用して圧縮)するなどの対処が必要です。 |
| 2 | 「在庫からの予約通知連絡」などの要素に○○○○番号などのような「000052」等の扱いをあえて行いたい個所があります。 「銀行口座番号」「登録番号」「通知番号」等は「integer」での取り扱いになるのでしょうか？ |
参照用途で使用する（機械的な処理をしないで人間がみる項目）はStringであっても問題ないため、TravelXML 1.1.1よりStrinｇに変更しました。 |
| 3 | 要求と応答の構造が同じものが多いですが、要求値をそのまま応答値として 返す場合を想定しているのでしょうか？ | その通りです。 |
| 4 | 宿泊料金にはクーポン差し引き前の"合計金額"と差し引き後の"支払金額"とが存在しますが、エレメント"TotalAccomodationCharge(合計宿泊料金（総額）)に"合計金額"を格納すると"支払金額"を格納するエレメントが足りないのでは？ どのエレメントに格納する想定でしょうか？ |
本メッセージは旅行会社と宿泊施設間の施設予約取引を範囲としているので、 ・旅行会社と宿泊施設間での清算については対象外(今後別メッセージで定義予定） ・顧客と旅行会社および顧客と宿泊施設との間での生じる決済についても対象外 そのため、支払金額を格納するための要素は定義していません。 |
| 5 | TaxServiceFee(税サ区分)の選択肢に"税込サ別"が存在しないのは何故ですか？ 税込サ込、税込サ別、税別サ込、税別サ別の４種類を全て用意すべきでは？ |
サービス料金自体にも消費税が掛かるため、「税込サ別」の場合は計算が複雑になることから一般的に使用されていないため、選択肢には含んでいません。 |
| 6 | 「国内施設情報編」における施設の場所を特定する情報としては住所が最も一般的とは思いますが、地図ソフトやナビゲーションソフト等の普及も考えますと、BasicInformation または StructureInformation の要素として緯度・経度情報があればと思います。 | 本メッセージは宿泊施設から旅行会社に送られる情報であり、旅行会社側では緯度・経度の情報は必要としない(情報のニーズが現状無い)ため、当該情報を追加する必要性は低いと判断しました。 ただし、宿泊施設側が持っている施設の属性情報として必要かどうかは、別な場での検討を行う必要があると思われます。 |
| 7 | 「国内取引データ」、「海外取引データ」以外のXML Schemaは公開されないのでしょうか？ | 残りの8取引に関してもXML Schemaを作成中です。作成が終わり次第公開を行っていく予定となっています。 |
| 8 | 「本編」の「付録A（参考）TravelXMLの送受信について」で、Webサービス方式での準拠する規格を「WS-I BP」にしないのはなぜですか？ | Webサービス方式では、XMLコンソーシアムで行われた「TravelXML利用Webサービス実証実験プロジェクト」での成果をベースにしており、実証実験プロジェクトでは「WS-I BP」での接続の検証を行っていないためです。 |
| 9 | WSDLの標準化の予定はあるのでしょうか？あるのであれば、いつごろ公開予定ですか？ | TravelXMLでは、データの交換方式を標準化のスコープとしていません。そのため、現状でWSDLを作成する予定もありません。 |
| 10 | 「Schema_and_Instance-1_4-PR」フォルダーのReadme.txtに以下の説明があります。 ％％ 使用上の注意事項 ％％ １．InstanceとXML Schemaの関連付けについて 一般的にInstanceとXML Schemaの関連付けを行うには、インスタンスを検証するアプリケーションに明示的に指定する方法とInstance内に属性として、XML Schemaファイルのパスを指定する方法とがあります。 XML Schemaのファイルパスを指定する場合、使用している環境やファイルの配置によって、具体的なパスの記述方法が異なります。 そのため、本Instanceでは、前者を使用して検証を行っています。 もし、アプリケーションに明示的にXML Schemaを指定する方法の無い環境でInstanceの検証を行うのであれば、Instanceのルートタグに下記のような記述を追加して下さい。 例． xsi:schemaLocation="ネームスペース名 XML Schemaファイルへのパス" ＃ネームスペースはInstanceによって異なります。 ＃XML Schemaファイルへのパスは、環境やファイルの配置によって異なります (c:\SchemaFile\xxxx.xsd[Windows],/home/usr/SchemaFile/xxxx.xsd[Unix系]) ここで、xsi:schemaLocationを追加するようにとの指示が書かれていますが、 xsi:schemaLocationを使うには、xsi接頭辞の宣言としてxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"という属性も指定しなければなりません。 この点をReadme.txtに追加する必要があります。 |
仕様上ご指摘が正しいため、TravelXML 1.4 勧告のXML Schemaの添付文書を修正いたしました。 |
| 11 | "01"〜"10"までのすべてのスキーマに共通して指摘させていただきたいことですが、代表して\05_txds\DomesticSettlement.xsdで説明します。このスキーマでは、SalesOfficeRegisteredPrefectureとSettlementCompanyRegisteredPrefectureにおいて全く同じEnumerationを使った単純型が使用されています。 <xs:element name="SalesOfficeRegisteredPrefecture"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="国土交通大臣"/> <xs:enumeration value="北海道知事"/> <xs:enumeration value="青森県知事"/> <xs:enumeration value="岩手県知事"/> <xs:enumeration value="宮城県知事"/> <xs:enumeration value="秋田県知事"/> <xs:enumeration value="山形県知事"/> <xs:enumeration value="福島県知事"/> <xs:enumeration value="茨城県知事"/> <xs:enumeration value="栃木県知事"/> <xs:enumeration value="群馬県知事"/> <xs:enumeration value="埼玉県知事"/> <xs:enumeration value="千葉県知事"/> <xs:enumeration value="東京都知事"/> <xs:enumeration value="神奈川県知事"/> ．．略 ．．．． <xs:enumeration value="沖縄県知事"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="SettlementCompanyRegisteredPrefecture"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="国土交通大臣"/> ．．．．．上記と全く同じ指定の繰り返し ．．．．． このような共通の型は、下記のようにグローバルな型宣言を使って共有した方がスキーマのメンテナンスの観点から考えても良いのではないでしょうか。 <xs:simpleType name="RegisteredPrefecture"> <xs:restriction base="xs:string"> <xs:enumeration value="国土交通大臣"/> <xs:enumeration value="北海道知事"/> <xs:enumeration value="青森県知事"/> <xs:enumeration value="岩手県知事"/> <xs:enumeration value="宮城県知事"/> <xs:enumeration value="秋田県知事"/> <xs:enumeration value="山形県知事"/> <xs:enumeration value="福島県知事"/> <xs:enumeration value="茨城県知事"/> <xs:enumeration value="栃木県知事"/> <xs:enumeration value="群馬県知事"/> <xs:enumeration value="埼玉県知事"/> <xs:enumeration value="千葉県知事"/> <xs:enumeration value="東京都知事"/> <xs:enumeration value="神奈川県知事"/> ．．．．略 ．．．． <xs:enumeration value="沖縄県知事"/> </xs:restriction> </xs:simpleType> <xs:element name="SalesOfficeRegisteredPrefecture" type="txds:RegisteredPrefecture"/> <xs:element name="SettlementCompanyRegisteredPrefecture" type="txds:RegisteredPrefecture"/> また、上記では1つのスキーマ内での型の宣言とその共用について述べましたが、このような共通の型で複数のスキーマにまたがって見受けられるものもあります。 たとえば、上記のRegisteredPrefectureは、(1)「国内取引データ」のDomesticBusinessCommunication.xsdにおいても使用されています。このような「認可する国や県の長」のリストなどは、今後のTravelXMLの拡張などでも使われる可能性がありますので、複数のスキーマ間の整合性を保ちつつメンテナンスを行うには、共通に使用される型をまとめて1つの名前空間として管理し、個々のスキーマでそれをインポートして使うことがより効果的であると思われます。 （共通の型だけを集めたスキーマ: commonTypes.xsd） <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://travelxml.jp/Common" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="RegisteredPrefecture"> <xs:restriction base="xs:string"> <xs:enumeration value="国土交通大臣"/> <xs:enumeration value="北海道知事"/> <xs:enumeration value="青森県知事"/> <xs:enumeration value="岩手県知事"/> <xs:enumeration value="宮城県知事"/> <xs:enumeration value="秋田県知事"/> <xs:enumeration value="山形県知事"/> <xs:enumeration value="福島県知事"/> <xs:enumeration value="茨城県知事"/> <xs:enumeration value="栃木県知事"/> <xs:enumeration value="群馬県知事"/> <xs:enumeration value="埼玉県知事"/> <xs:enumeration value="千葉県知事"/> <xs:enumeration value="東京都知事"/> <xs:enumeration value="神奈川県知事"/> ．．．．略 ．．．． <xs:enumeration value="沖縄県知事"/> </xs:restriction> </xs:simpleType> </xs:schema> （DomesticBusinessCommunication.xsd） <xs:schema targetNamespace="http://travelxml.jp/:Draft:DomesticBusinessCommunication :SpecVerison=1.4:SchemaVersion=1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:txdc="http://travelxml.jp/:Draft:DomesticBusinessCommunication: SpecVerison=1.4:SchemaVersion=1.0" elementFormDefault="qualified" xmlns:common="http://travelxml.jp/Common"> <xs:import namespace="http://travelxml.jp/Common" schemaLocation="commonTypes.xsd"/> ．．．．略 ．．．． <xs:element name="RetailerRegisteredPrefecture" type="common:RegisteredPrefecture" /> （DomesticSettlement.xsd） <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://travelxml.jp/:Draft:DomesticSettlement: SpecVerison=1.1:SchemaVersion=1.0" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:txds="http://travelxml.jp/:Draft:DomesticSettlement: SpecVerison=1.1:SchemaVersion=1.0" xmlns:common="http://travelxml.jp/Common" > <xs:import namespace="http://travelxml.jp/Common" schemaLocation="commonTypes.xsd"/> ．．．．略 ．．．． <xs:element name="SalesOfficeRegisteredPrefecture"type="common:RegisteredPrefecture"/> ．．．．略 ．．．． <xs:element name="SettlementCompanyRegisteredPrefecture" type="common:RegisteredPrefecture"/> |
TravelXMLでは、旅行業界における取引毎に共通な枠組みを用いながら、それぞれの独立性はある程度保てるように仕様作成を行ってまいりました。上記によって、TravelXMLを採用する企業または団体は自分たちの必要とする取引のみを選んで、採用を検討することができるようになっております。そのため、ある取引での見直しが他の取引に波及しないようXML Schemaも独立させ、Namespaceも異なるものを使用しています。将来的に普及が進み、複数取引を同時に採用する企業が増え、項目の共通化が必要となった際に、改めて項目そのものの共通化を含めて検討させていただきます。しかし、同じXML Schema内に同じEnumerationを持つTypeが複数ある現状のXML Schemaの可読性が低いことは確かですので、TravelXML 1.4.1 勧告案では、一つのXML Schema内で同じEnumerationを持つ要素のType定義を一元化しました。 |
| 12 | (7)「旅行会社情報」では、日本語の旅行会社情報と英語の旅行会社情報の２つのパターンで情報提供するよう１つのスキーマが定義されています。言語の違いによる構造の違いはなく、要素内容としての文字列を英語にするか日本語にするかだけの違いです。 このスキーマでは、日本語用のルート要素、英語用のルート要素がそれぞれ設けられ、下位構造は全く同じになっています。 ．．．． <xs:element name="TravelCompanyInformationInEnglish"> <xs:complexType> <xs:sequence> <xs:element ref="txci:TransactionType"/> <xs:element ref="txci:DataManagementInformation"/> <xs:element ref="txci:TravelCompanyHeadOfficeInformation"/> <xs:element ref="txci:TravelCompanyHandlingBusiness" minOccurs="0"/> <xs:element ref="txci:DomesticTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:DomesticTravelSellingImportantDestination" minOccurs="0"/> <xs:element ref="txci:OverseasTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:OverseasTravelSellingImportantArea" minOccurs="0"/> <xs:element ref="txci:InboundTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:InboundTravelAcceptanceCountry" minOccurs="0"/> <xs:element ref="txci:SalesOfficeBasicInformation" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="TravelCompanyInformationInJapanese"> <xs:complexType> <xs:sequence> <xs:element ref="txci:TransactionType"/> <xs:element ref="txci:DataManagementInformation"/> <xs:element ref="txci:TravelCompanyHeadOfficeInformation"/> <xs:element ref="txci:TravelCompanyHandlingBusiness" minOccurs="0"/> <xs:element ref="txci:DomesticTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:DomesticTravelSellingImportantDestination" minOccurs="0"/> <xs:element ref="txci:OverseasTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:OverseasTravelSellingImportantArea" minOccurs="0"/> <xs:element ref="txci:InboundTravelHandlingRange" minOccurs="0"/> <xs:element ref="txci:InboundTravelAcceptanceCountry" minOccurs="0"/> <xs:element ref="txci:SalesOfficeBasicInformation" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> ．．．． このように構造が全く同じ中で、英語と日本語を使い分けるために、いくつかの型でEnumeration要素には日本語の指定項目と英語の指定項目が併記されています。 <xs:element name="ANTAMember"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="正会員"/> <xs:enumeration value="賛助会員"/> <xs:enumeration value="Avtive Members"/> <xs:enumeration value="Allied Members"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="JATAMember"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="正会員"/> <xs:enumeration value="協力会員"/> <xs:enumeration value="Active Members"/> <xs:enumeration value="Associate Members"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="RegisteredCategory"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1種"/> <xs:enumeration value="2種"/> <xs:enumeration value="3種"/> <xs:enumeration value="代理業"/> <xs:enumeration value="First-category"/> <xs:enumeration value="Second-category"/> <xs:enumeration value="Third-category"/> <xs:enumeration value="TravelSubAgent"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="RegisteredPrefecture"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="国土交通大臣"/> <xs:enumeration value="北海道知事"/> <xs:enumeration value="青森県知事"/> ．．．．略 ．．．． <xs:enumeration value="沖縄県知事"/> <xs:enumeration value="MLIT"/> <xs:enumeration value="Hokkaido-pref."/> <xs:enumeration value="Aomori-pref."/> ．．．．略 ．．．． <xs:enumeration value="Okinawa-pref."/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="TransactionType"> <xs:complexType> <xs:sequence> <xs:element ref="txci:DataFrom"/> <xs:element ref="txci:DataClassification"/> <xs:element ref="txci:DataID"/> <xs:element ref="txci:SystemDate"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DataClassification"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="TravelCompanyInformationInJapanese"/> <xs:enumeration value="TravelCompanyInformationInEnglish"/> </xs:restriction> </xs:simpleType> </xs:element> これについて以下の問題があります。 （１） TravelCompanyInformationInEnglish要素 、TravelCompanyInformationInJapanese要素を使ったところで、その内容として指定する文字列が日本語あるいは英語のどちらでも書けるような構造になってしまう。 （２） TravelCompanyInformationInEnglish要素 、TravelCompanyInformationInJapanese要素の子要素TransactionTypeで" TravelCompanyInformationInJapanese "または" TravelCompanyInformationInEnglish "を指定することになっているが、これは、ルート要素によってすでに自明な内容であり意味的に二重指定となっている。しかも、親要素がTravelCompanyInformationInEnglish であるかTravelCompanyInformationInJapaneseであるかに関わらず" TravelCompanyInformationInJapanese "、"TravelCompanyInformationInEnglish "のどちらでも指定できるため、意味的に矛盾したインスタンスが書けてしまう。 現状のスキーマをより分かりやすいスキーマに整理するには以下の２通りの方法が考えられます。 （A） TravelCompanyInformationInEnglish要素 、TravelCompanyInformationInJapanese要素をルート要素とする２つの異なるスキーマを用意する。これによって、それぞれのスキーマ内の型宣言において、Enumerationによる指定項目を英語、日本語のどちらかに統一できる。 この場合、上記（２）の問題は依然として残るので、TransactionType要素は削除します。 （B） TravelCompanyInformationInEnglish要素 、TravelCompanyInformationInJapanese要素という区別を止め、TravelCompanyInformation要素とする。日本語か英語かは、TransactionType要素で区別する。 この場合、Enumerationによる指定項目は英語、日本語併用になるので、間違った記述をしないようアプリケーションレベルでチェックする必要があります。 |
項番11と同様の理由から取引ごとにXML Schemaを作成する方針のため、XML Schemaでの妥当性検証では検証しきれず、アプリケーションによるチェックが必要な項目も存在していますが、XMLインスタンス内での要素間の値の依存関係等は、XML Schemaを使用してもすべてを定義することは不可能なこともあり、TravelXMLではアプリケーションによる値のチェックを前提としております。 本メッセージにおいては国内旅行会社から国内外の宿泊施設へのメッセージ送信を対象としており、Enumeration以外の要素の日本語、英語のチェックは、アプリケーションによるチェックが必要であり、Enumrationも同じ方法でチェックが可能です。 しかし、前記と同様にXML Schemaの作成方針を含めたTravelXML全体の見直しが必要となった際の課題として認識しております。 |
| 13 | TravelXML 1.4 勧告案のP17 「07-02-01-02 DataClassification」のEnumerationおよびSampleがP15の旅行会社情報 日本語と同じである。 「TravelCompanyInformationInEnglish」となるのではないか？ |
仕様上ご指摘が正しいため、TravelXML 1.4 勧告において修正いたしました。 |