stanford-oval/wikipedia huggingface dataset:
スズキ・アドレス
外部リンク・公式以外

BBB The History 時代を彩ったバイクたち スズキ アドレスV100 概要
Webike（ウェビック） - 車種別カタログ - スズキ ADDRESS V50総合情報
Webike（ウェビック） - 車種別カタログ - スズキ ADDRESS V100総合情報
Webike（ウェビック） - 車種別カタログ - スズキ ADDRESS 110総合情報
Webike（ウェビック） - 車種別カタログ - スズキ ADDRESS V125総合情報
| 表 話  歴スズキのオートバイの車種 |
| --- | --- | --- |
| 50 cc |  GA50  GN50E  GS50  Hi（ハイ）/-R/-UP/-UP R  K50  OR50マメタン  RC50  RG50/E/T  RG50Γ  TS50ハスラー  OM50ミニタン  PV50エポ  ZZ  アドレス50/V50  ウルフ（RT50）  ウルフ50（TV50M）  カーナ  ギャグ  コレダスポーツ/コレダスクランブラー  ジェンマ50  シュート  スージー  スーパーモレ  ストリートマジック50/50II  スワニー  セピア/セピアZZ  チョイノリ  バーディー50  ヴェルデ  モードGT  ユーディミニ  ラブ/ラブIII  ランディー  レッツ/レッツII  レッツ4/パレット/バスケット  レッツ5/G  レッツ (2015-)  薔薇  蘭  |  |
| 51 - 125 cc |  DF125  DR125S（英語版）  GP125  GT100  GT125  GN125  GS125E（カタナ）  GSX-R125  GSX-S125  K90/125  RA125  RG80E  RG125/E  RG125Γ  RV75/90/125（バンバン）  SX125R  T125  TS125R  アドレス110  アドレスV100  アドレス125  アドレスV125  アドレスV125S/Sベーシック/Sリミテッド  アヴェニス125  イントルーダーLC125  ウルフ90（T90）  ウルフ125/II（T125）  ウルフ125（TV125）  ジェベル125  ジェンマ80/90/125  ストリートマジック110/110II  バーグマン125  バーディー70/80/90  ヴェクスター125  マローダー125  スウィッシュ125  |  |
| 126 - 250 cc |  GSX-R150  GSX-S150  250SB  DF200  DR200S（英語版）  DR250S/DR250R  GF250（英語版）  GN250/E  GS250FW  GSR250/S/F  GSX250E（カタナ）/GSX250L/GSX250T  GSX250FX  GSX250R  GSX250Sコブラ  GSX250SSカタナ  GSX-R250/R  GT185  GT250  NZ250/S  RG200Γ  RG250  RG250Γ  RGV250Γ  RH250  ST250/Etype  SX200R  SW-1  T20  T200  T250  TS250  TS200R  Vストローム250  アクロス  アヴェニス150  イントルーダーLC250  ウルフ200  ウルフ（TV250J）  グース250  グラストラッカー/ビッグボーイ  ジェベル200  ジェベル250XC  ジェンマ  ジクサー  スカイウェイブ250S/SS/M/リミテッド  バンディット250/リミテッド/V/VZ  バーグマン200  バンバン200  ヴェクスター150  ボルティー  マローダー250  |  |
| 251 - 400 cc |  DR350  DR-Z400S/SM  GS400E  GSR400  GSX400E（カタナ）/GSX400L  GSX400F/FII/FSインパルス  GSX400FW  GSX400Sカタナ  GSX400X/XSインパルス  GSX400インパルス（インパルス400）  GSX-F（GSX400F）  GSX-R400  GT380  RF400R/RV（英語版）  RG400Γ  SP370  SV400/S  T350  イナズマ  イントルーダー400/クラシック400  グース350  グラディウス400  サベージ400  スカイウェイブ400S/リミテッド  デスペラード400/X/ワインダー  テンプター  バンディット400/リミテッド/V/VZ  バーグマン400  ブルバード400  |  |
| 401 - 750 cc |  DR650（英語版）  GR650  GS500(E)/F  GS550M  GS650G  GS750/E/G（英語版）  GSF750  GSR600/750  GSX750E  GSX750S（カタナ）  GSX600F/650F/750F  GSX-R600  GSX-R750  GSX-S750  GT500  GT550  GT750  RF600  RE-5  RG500Γ  T500  VS700/VS750イントルーダー  グラディウス650  SV650/S/SF  Vストローム650/XT  XN85（英語版）  サベージ650  スカイウェイブ650/LX  |  |
| 751 cc - |  B-KING  DR800（英語版）  GS1000  GS1200SS  GSF1200/S  GSX1100F  GSX1100Sカタナ  GSX1400  GSX-S1000/F  GSX-R1000  GSX-R1100  RF900R  SV1000S  TL1000S/TL1000R  VS1400イントルーダー  Vストローム1000/XT  VX800  イントルーダー800/クラシック800  イントルーダーLC（VL1500）  デスペラード800/X  バンディット1200/S  バンディット1250/S/F  ブルバード800  ブルバードC90（C1500）  ブルバードM90  ブルバードM109R（M1800R）  マローダー800  マローダー1600  隼  |  |
| 系列 |  DR  DR-Z  GN  GS  GSR  GSX  GSX-F  GSX-S  GSX-R  GT  K  RG  SV  T  TS  アドレス  イントルーダー  インパルス  ウルフ  カタナ  ガンマ  ジェベル  ジェンマ  スカイウェイブ  バーグマン  バーディー  バンディット  バンバン  ブルバード  マローダー  レッツ  |  |
| 電動スクーター |  e-Let's/W（原付一種・定格出力580W）  |  |
| 競技車両 |  ロードレーサー  RGV-Γ500  GSV-R  GSX-RR  DR-Z50  DR-Z70  DR-Z125/L  RM  RM-Z450/250  JR  PE  |  |
  カテゴリ
XML-RPC

XML-RPCとは、遠隔手続き呼出し (RPC) プロトコルの一種であり、エンコード（符号化）にXMLを採用し、転送機構にHTTPを採用している。非常に単純なプロトコルで、少数のデータ型やコマンドだけを定義しているだけであり、その仕様は2枚の紙にまとめられる。これは多くのRPCシステムが膨大な量の規格を規定し、実装に多量のプログラミングを要することに比べると、際立った特徴と言える。
1998年、ユーザーランド・ソフトウェアがマイクロソフトと共同で開発した。その後、これに新たな機能を追加したものがSOAPへと発展した。しかし、SOAP よりも単純で扱いやすいXML-RPCを好む人もいる。
類似の RPCプロトコルとして JSON-RPC がある。
データ型

| 名称 | タグ使用例 | 説明 |
| --- | --- | --- |
| array |  <array>   <data>     <value><i4>1404</i4></value>     <value><string>Something here</string></value>     <value><i4>1</i4></value>   </data> </array> | 値の配列。キーは格納しない。 |
| base64 |  <base64>eW91IGNhbid0IHJlYWQgdGhpcyE=</base64> | Base64でエンコードされたバイナリデータ |
| boolean |  <boolean>1</boolean> | ブーリアン型の論理値（0または1） |
| date/time |  <dateTime.iso8601>19980717T14:08:55</dateTime.iso8601> | 日付と時刻 |
| double |  <double>-12.53</double> | 倍精度浮動小数点数 |
| integer |  <i4>42</i4> または <int>42</int> | 整数 |
| string |  <string>Hello world!</string> | 文字列。XMLのエンコード規則に従う。 |
| struct |  <struct>   <member>     <name>foo</name>     <value><i4>1</i4></value>   </member>   <member>     <name>bar</name>     <value><i4>2</i4></value>   </member> </struct> | キーを含む値の配列。 |
| nil |  <nil/> | NULL値の識別用。XML-RPC の拡張 |
例

XML-RPC要求の典型例を以下に示す。
<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>
        <value><i4>40</i4></value>
    </param>
  </params>
</methodCall>
XML-RPC応答の典型例を以下に示す。
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
        <value><string>South Dakota</string></value>
    </param>
  </params>
</methodResponse>
XML-RPCフォールトの典型例を以下に示す。
<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>4</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>Too many parameters.</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>
奈良市立神功小学校

| 奈良市立神功小学校 Jinguu elementary school |
| --- | --- |
 
 北緯34度43分12秒 東経135度46分42秒﻿ / ﻿北緯34.71992度 東経135.77833度﻿ / 34.71992; 135.77833座標: 北緯34度43分12秒 東経135度46分42秒﻿ / ﻿北緯34.71992度 東経135.77833度﻿ / 34.71992; 135.77833
国公私立の別:  公立学校
設置者:   奈良市
共学・別学:  男女共学
学期:  3学期制
学校コード:  B129210000356 
所在地:  〒631-0804
 奈良県奈良市神功二丁目2
外部リンク:  公式サイト
 ウィキポータル 教育  ウィキプロジェクト 学校
テンプレートを表示
奈良市立神功小学校（ならしりつ じんぐうしょうがっこう）は、奈良県奈良市神功二丁目に存在した公立小学校。
沿革

1980年 - 開校。
2022年3月 - 閉校。右京小学校と統合され平城西中学校の敷地に施設一体型小中一貫校として2022年4月に開校した奈良市立ならやま小中学校に引き継がれる。
通学区域

神功一丁目、神功二丁目、神功三丁目、神功四丁目、神功五丁目、神功六丁目
神奈川県自然環境保全センター

神奈川県自然環境保全センター（かながわけんしぜんかんきょうほぜんセンター）は、自然環境の保全再生を推進する県の機関。2009年（平成21年）7月17日に神奈川県立自然保護センターから改称した。
主な業務

丹沢大山自然再生事業の実施
自然公園の管理指導及び施設整備
野生生物の保護管理
自然環境保全に係る普及啓発
県営林の管理経営
など
施設所在地

自然環境保全センター：神奈川県厚木市七沢657
箱根出張所：神奈川県足柄下郡箱根町元箱根旧札場164
足柄出張所：神奈川県足柄上郡開成町吉田島2489-2（県足柄上合同庁舎内）
さいたま市立美園小学校

| さいたま市立美園小学校 |
| --- | --- |
 
 ja北緯35度53分26.26秒 東経139度44分6.68秒﻿ / ﻿北緯35.8906278度 東経139.7351889度﻿ / 35.8906278; 139.7351889座標: 北緯35度53分26.26秒 東経139度44分6.68秒﻿ / ﻿北緯35.8906278度 東経139.7351889度﻿ / 35.8906278; 139.7351889
国公私立の別:  公立学校
設置者:  さいたま市
設立年月日:  2012年（平成24年）4月1日
共学・別学:  男女共学
学期:  3学期制
学校コード:  B111210900106 
所在地:  〒336-0967
 埼玉県さいたま市緑区美園5丁目33番地
外部リンク:  公式サイト
 ウィキポータル 教育  ウィキプロジェクト 学校
テンプレートを表示
さいたま市立美園小学校（さいたましりつ みそのしょうがっこう）は、埼玉県さいたま市緑区美園五丁目にある公立小学校。
規模

市内で最も新しい小学校であったが、児童数がみそのウイングシティの開発に伴い増加しているため、埼玉スタジアム2002南側に美園北小学校が建設され、2019年4月に分離独立している。
沿革

2012年（平成24年）
4月1日 - さいたま市立大門小学校・さいたま市立野田小学校・さいたま市立新和小学校から分離独立し、さいたま市立美園小学校として開校。
4月9日 - 開校式と第1学期始業式及び第1回入学式挙行。開校時点の児童数539名・学級数19学級・教職員51名でスタートを切った。
5月24日 - PTA臨時総会開催。
11月21日 - 落成式挙行。
2013年（平成25年）3月22日 - 第1回卒業証書授与式挙行。
2017年（平成29年）3月31日 - 仮設校舎完成。
2019年（平成31年・令和元年）
3月26日 - 美園北小学校開校に伴う分校式挙行。
12月26日 - 仮設校舎取り壊し。
2021年（令和3年）2月16日 - V2Xが完成し、説明・引き渡しが行われた。
沿革 > この節の出典

美園小学校沿革（学校ホームページ内） (PDF)
学区

緑区美園5〜6丁目
交通

国際興業バス「浦02」・「浦02S」・「岩11-3」・「岩11-3S」の各系統で、「野台団地西」バス停下車後、徒歩約270m・約5分（直線距離は約90mと近いが、道路の関係で遠廻りとなる）。
JR東日本浦和駅（東口）、JR東日本・埼玉高速鉄道東川口駅（北口）、東武鉄道岩槻駅から、上述の国際興業バスで、「野台団地西」バス停下車後、徒歩。
埼玉高速鉄道浦和美園駅から、
上述の国際興業バス「浦和02」で「野台団地西」バス停下車後、徒歩。
駅から徒歩10分。
アミノレブリン酸シンターゼ

アミノレブリン酸合成
アミノレブリン酸シンターゼ(Aminolevulinic acid synthase)とは、グリシンと転移酵素 EC 2.3.1.37．スクシニルCoAを基質、ピリドキサールリン酸を補酵素として5-アミノレブリン酸を合成する酵素である。ミトコンドリア内に所在する。
ヘム合成の第1段階の反応である。ヒトにおいてはアミノレブリン酸シンターゼの転写は、鉄と結合していないポルフィリン中間体の蓄積を防ぐために、ポルフィリンとの結合要素である Fe2+ の存在の有無によって厳密に管理されている。体内には2種類のアミノレブリン酸シンターゼが存在する。1つは、赤血球前駆細胞で発現し、もう1つは全身で発現するものである。赤血球の形成は、X染色体上の遺伝子に記述されているが、もう1つは3染色体の遺伝子上に記述されている。X染色体に関連した鉄芽球性貧血は、X染色体上のアミノレブリン酸シンターゼの遺伝子の変異によって起こるが、もう1つの遺伝子の変異は何の疾患も発生させない。
アミノレブリン酸シンターゼは、補因子であるピリドキサールリン酸とともにグリシンからカルボキシル基を離脱させ、スクシニルCoAからCoAを離脱させ、分子中の4番目の炭素上のアミノ基を意味するδ-アミノレブリン酸を形成する。
δ-アミノレブリン酸からプロトポルフィリンIXまでの生合成経路
田代順七

| 田代順七 |
| --- | --- |
 画室で製作中の田代順七
生誕:   (1900-03-13) 1900年3月13日
死没:  1985年10月11日(1985-10-11)（85歳没）
国籍:   日本
著名な実績:  洋画
代表作:  「球磨川」(1950)、「天草」、「阿蘇」（シリーズ）
 
テンプレートを表示
田代 順七（たしろ じゅんしち）1900年（明治33年）3月13日 - 1985年（昭和60年）10月11日）は、昭和期の洋画家。現在の熊本県玉名市出身。
教員を務める傍ら熊本在住者として初めて帝展入選を果たし、以後1985年まで、文展（文部省美術展覧会、現在の日展）、日展に連続出品。具象絵画団体東光会支部としての銀光会を結成し、熊本の洋画史をリードしながら郷土熊本の自然の美をテーマに一貫して具象絵画の世界を追求、熊本における美術振興に寄与した。
その絵画精神は自然観照にもとづく美学の実践であり、力強く表現されている。
画業60余年、とりわけ1950年代中頃から展開する「球磨川」「天草」そして晩年の「阿蘇」シリーズの作品は、田代芸術の写実観を如実に物語っている。
経歴

1900年3月13日 熊本県玉名郡築山村山田（現玉名市山田）に生まれる。
1918年 看板屋に入り独学で油絵を勉強。
1926年 玉名郡神尾小学校に図画専科正教員として勤務。
1933年 東光展初入選。
1934年 熊本在住者として初めて帝展入選を果たし、以後1985年まで、文展（文部省美術展覧会、現在の日展）、日展（日本美術展覧会）に連続出品。これを機に太田黒幸、松岡正直、米村潤之らと具象絵画団体東光会支部としての銀光会を結成する。
1936年 熊本市立高等女学校（現熊本市立必由館高等学校）教諭となる。（1960年退職）
1955年 「河畔」で日展特選。
1968年 熊本女子短期大学（現尚絅大学短期大学部）教授となる。（1975年退職）
1971年 熊本県美術家連盟が結成され初代会長となる。
1973年 熊本県教育委員会から第26回熊本県近代文化功労者として顕彰される。
1974年 地方文化功労者として叙勲（勲五等双光旭日章）。
1980年 熊本県文化懇話会から第8回芸術功労者として表彰される。
1985年 熊本県立美術館にて「田代順七展」開催。同展開催中に死去。
1996年 「熊本市所蔵品展－熊本の画家たち」（熊本県立美術館分館）。
2003年 絵画作品が20点熊本市に寄贈される。
2004年 「キュレーターズ・セレクション CAMKコレクションⅠ」（熊本市現代美術館）
主な作品

「海辺小景」1937年東光賞（熊本県立美術館）
「河畔」1955年第11回日展特選（熊本県立美術館）
「夏の天草」1958年第1回新日展（熊本県立美術館）
「川畔風景」1960年（熊本県立美術館）
「雪の阿蘇」1975年（熊本県立美術館）
「水辺」1967年（個人蔵）
「天草」1967年（熊本市現代美術館）
「球磨川にて」1968年（熊本市現代美術館）
「夏の熊本城」1979年（熊本市蔵）
「阿蘇」1985年（熊本県立美術館）
ギャラリー

貝焼場 1942年 145.3×112.1cm 第5回新文展
湖畔 1955年 112.1×145.5cm 第11回日展 特選
岩 1953年 112.1×145.5cm 第9回日展
夏の天草 1958年 130.3×162.1cm 第1回新日展
阿蘇 1970年 121.1×145.5cm 第4回九州沖縄芸術祭・九州沖縄洋画展
阿蘇外輪 1971年 121.1×145.5cm 第3回日展
阿蘇1980 1980年 121.1×145.5cm 第46回東光展
曇りの日の外輪 1974年 112.1×145.5cm 第6回日展
晩夏の庭先 100号 油絵
鳥小屋 「鳥小屋」 90.5×116.0cm
パリの片隅 スケッチ
XSL Transformations

| --- | --- |

拡張子: .xsl, .xslt
MIMEタイプ: application/xslt+xml
開発者: World Wide Web Consortium (W3C)
種別: XML変換言語、関数型言語
派生元: XML
国際標準: 1.0 (Recommendation),   2.0 (Recommendation),   3.0 (Recommendation)
XML変換におけるXSLTの位置付け
XSL変換（英: XSL Transformations、XSLT）は、W3Cにより標準化されたXML文書の変換用言語である。3つの仕様から成るXSLのうちの、ひとつの仕様である。XSLT の仕様はジェームズ・クラークを中心とした人々が設計した。XSLT と XSL-FO はDSSSLをもとにして設計された。
XSLT 1.0 は1999年11月23日にW3C勧告となり、2007年には JIS X 4169 としてJIS規格へ翻訳された。XSLT 2.0 は2007年1月23日に、3.0は2017年6月8日にW3C勧告となった。
XSLTはXML形式の文書を変換する。XPath による選択と検索にもとづき、XML文書全体または文書の一部に対して変換を行い、XML として出力する他、XML（整形式）ではないその他任意のテキスト形式としても出力できる。
例としては次のような応用がある。
一定フォーマットのHTML用の、文書型宣言・ヘッダ情報の追加
テキストの移動
テキストのソート
変換の指定は関数型言語として見ることもでき、実のところチューリング完全であるため、コンピュータ・プログラムを書くようにしてどんな応用も可能である。裏返せば、その機能を十分に発揮させるためには利用者に通常のプログラミングと同様の能力と作業が必要であり、しばしばXMLに対して持たれている「プログラミングが不要」という期待を裏切るものではある。
変換の対象となるXML文書は木構造であり、XSLTによる変換は宣言的に指定される。つまり、XSLTプログラムは、変換をどう行うべきか指定する規則をいくつか集めたものからなり、この規則を再帰的に適用することによって変換を行う。
XSLT処理系はまずどの規則が適用できるかチェックし、優先順にもとづいて該当する変換を行う。
XSLTプログラムは、以下のようにXML文書の形式をとる。
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 ...
</xsl:stylesheet>
データ変換

XML 形式のデータを様々な形式のデータに変換できる。ここではその例を示す。
変換前のXML
<?xml version="1.0" ?>
<persons>
  <person username="JS1">
    <name>John</name>
    <family-name>Smith</family-name>
  </person>
  <person username="MI1">
    <name>Morka</name>
    <family-name>Ismincius</family-name>
  </person>
</persons>
| 変換後の形式 | XSLTコード | 変換結果 |
| --- | --- | --- |
| XML | <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">   <xsl:output method="xml" indent="yes"/>    <xsl:template match="/persons">     <root>       <xsl:apply-templates select="person"/>     </root>   </xsl:template>    <xsl:template match="person">     <name username="{@username}">       <xsl:value-of select="name" />     </name>   </xsl:template>  </xsl:stylesheet>  | <?xml version="1.0" encoding="UTF-8"?> <root>   <name username="JS1">John</name>   <name username="MI1">Morka</name> </root>  |
| XHTML | <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet   version="1.0"   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"   xmlns="http://www.w3.org/1999/xhtml">    <xsl:output method="xml" indent="yes" encoding="UTF-8"/>    <xsl:template match="/persons">     <html>       <head> <title>Testing XML Example</title> </head>       <body>         <h1>Persons</h1>         <ul>           <xsl:apply-templates select="person">             <xsl:sort select="family-name" />           </xsl:apply-templates>         </ul>       </body>     </html>   </xsl:template>    <xsl:template match="person">     <li>       <xsl:value-of select="family-name"/><xsl:text>, </xsl:text><xsl:value-of select="name"/>     </li>   </xsl:template>  </xsl:stylesheet>   | <?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml">   <head> <title>Testing XML Example</title> </head>   <body>     <h1>Persons</h1>       <ul>         <li>Ismincius, Morka</li>         <li>Smith, John</li>       </ul>   </body> </html>  |
| CSV | <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet   version="1.0"   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">    <xsl:output method="text" encoding="UTF-8"/>    <xsl:template match="/persons">     <xsl:apply-templates select="person" />   </xsl:template>    <xsl:template match="person">     <xsl:value-of select="@username" />     <xsl:text>,</xsl:text>     <xsl:apply-templates select="*" />   </xsl:template>    <xsl:template match="name">     <xsl:value-of select="." />     <xsl:text>,</xsl:text>   </xsl:template>    <xsl:template match="family-name">     <xsl:value-of select="." />     <xsl:text>&#10;</xsl:text>   </xsl:template>  </xsl:stylesheet>  |  JS1,John,Smith MI1,Morka,Ismincius |
テンプレート関数

XSLT はテンプレートの関数を再帰的な形で定義ができる純粋関数型言語でもある。
下記のものはテンプレート関数 String_replaceAllである。これは、パラメーター this で指定した文字列中にある、パラメーター substring で指定した部分文字列をすべて、パラメーター replacement で指定する文字列に置換した文字列を返す関数。これの例から以下の点が分かる。
テンプレート関数の定義の仕方（xsl:template、xsl:param）
引数の値の参照の仕方（$引数名）
条件分けの仕方（xsl:if、xsl:choose）
XSLT関数（not、contains、substring-before、substring-after）
XSLT関数の使い方（<xsl:value-of select="XSLT関数 (引数...)" />）
定義されたテンプレート関数の呼び出し方（xsl:call-template、xsl:with-param：再帰呼び出しの箇所）
<?xml version="1.0" encoding="ISO-8859-1" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="String_replaceAll">
  <!-- 引数 -->
  <xsl:param name="this" select="''" />
  <xsl:param name="substring" />
  <xsl:param name="replacement" />

  <xsl:if test="not ($this='')">
    <xsl:choose>
      <!-- this に substring が含まれる場合の値 -->
      <xsl:when test="contains ($this, $substring)">
        <xsl:value-of select="substring-before ($this, $substring)" />
        <xsl:copy-of select="$replacement" />
        <xsl:call-template name="String_replaceAll"> <!-- 再帰呼び出し -->
          <xsl:with-param name="this" select="substring-after ($this, $substring)" />
          <xsl:with-param name="substring" select="$substring" />
          <xsl:with-param name="replacement" select="$replacement" />
        </xsl:call-template>
      </xsl:when>

      <!-- そうでない場合の値 -->
      <xsl:otherwise>
        <xsl:value-of select="$this" />
      </xsl:otherwise>
    </xsl:choose>
  </xsl:if>
</xsl:template>
</xsl:stylesheet>
メディア型

XSLTのメディア型は、「application/xslt+xml」としてIANAに登録されており、「application/xslt+xml」または「application/xml」が望ましいMIMEタイプである。しかし、Internet Explorerなど一部のユーザーエージェントには、これらのMIMEではXSLTを認識しないものや、「text/xsl」などの独自に定めたMIMEのみを認識するものも多い。
髙柳邦夫

髙柳 邦夫（たかやなぎ くにお、1947年2月20日 - ） は、日本の物理学者。東京工業大学栄誉教授。日本学士院賞受賞。紫綬褒章受章。アメリカ物理学会フェロー。
人物・経歴

東京都文京区出身。1969年東京工業大学理学部物理学科卒業。1971年東京工業大学大学院理工学研究科修士課程修了。1972年東京工業大学大学院理工学研究科博士課程中退、東京工業大学理学部助手。
1976年東京工業大学より理学博士の学位を取得。1977年フリッツ・ハーバー研究所リサーチフェロー。1981年東京工業大学理学部助教授。1989年東京工業大学大学院理工学研究科教授。1994年東京工業大学大学院総合理工学研究科教授。2001年東京工業大学大学院理工学研究科教授。2006年日本表面科学会会長。2007年日本顕微鏡学会会長。2012年東京工業大学大学院理工学研究科教授任期満了退任、東京工業大学大学院理工学研究科特任教授、東京工業大学名誉教授、東京工業大学栄誉教授。2015年東京工業大学大学院理工学研究科特任教授退任。
元国際顕微鏡学会連合(IFSM)理事。アメリカ物理学会(APS)フェロー、応用物理学会フェロー、日本表面科学会名誉会員、日本顕微鏡学会名誉会員。
著書

『基礎から学ぶ力学』（小野昱郎と共著）森北出版 2019年
受賞

日本電子顕微鏡学会瀬藤賞 1981
日本結晶学会賞 1982
応用物理学会賞 1987
仁科記念賞 1987
国際表面構造学会賞 1999
韓国真空学会賞 1999
日本表面科学会賞 2001
真空科学・技術・応用国際連合賞 2001
東レ科学技術賞 2002
紫綬褒章 2003
Grade Langmuir Award 2004
江崎玲於奈賞 2008
日本学士院賞 2012
東京工業大学栄誉教授 2012
瑞宝中綬章 2020
アプリケーションプログラミングインタフェース

| --- | --- |
: ウィキペディアなど、MediaWikiに対して使えるAPIについては、MediaWikiの解説ページをご覧ください。
アプリケーションプログラミングインタフェース（API、英: application programming interface）とは、広義ではソフトウェアコンポーネント同士が情報をやりとりするインタフェースの仕様である。
APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラリ（例えば、C++のStandard Template LibraryやJava API（英語版）など）がある。
商業的に使われる狭義では、各種システムやサービス（ハードウェア、OS、ミドルウェアおよびWebサービス等）を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ライブラリは含まない。
APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。
概要

広義のAPIでは単なるライブラリのインタフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。
前述のとおりAPIは各種システム／サービスがそのシステム／サービスを利用するアプリケーションに対して公開するインタフェースである。APIの重要な役割は、システム／サービス提供者が公式に仕様（外部仕様）を定義し、管理している各種機能を利用するための操作方法（インタフェース）を提供することである。APIは多くの場合、アプリケーションを構築する言語と同じ言語のライブラリ、あるいは通信プロトコル形式として提供され、システム／サービス開発者によって提供・管理される。
APIと非API

アプリケーションがシステム／サービスを利用するには、APIを無視してシステム／サービスの現在の実装および内部仕様に依存した方法がある。人と同じ操作をアプリケーションにさせたり、たまたま設定が書き込まれていたファイルをアプリケーションで読み取るなどである。この手法を非APIと言い英語圏ではnon-APIあるいはnon APIと呼ぶ。システム／サービス提供者はアプリケーションがAPI以外の仕様や実装に依存していることは関知せず、API以外の仕様や実装が永続的に維持されることも保証しない。このため非APIを使ったアプリケーションは、バグ修正などで少しでもシステム／サービスの内部仕様に変更があれば、たちまち動かなくなってしまう。この点、APIを使用する場合は、システム／サービスが更新されてもAPIが提供者によって後方互換性を維持してくれるため、アプリケーション側の変更は必要ない(ただし頻繁ではないが提供者により互換性がなくなる場合もある)。アプリケーションがシステム／サービスを操作するにあたり、APIにだけ依存することでこのような互換性の問題を避けることができる。
ただし、APIを使う場合、APIの提供者から使用回数などに制限を掛けられる場合がありそれをらの制限を回避するためやAPIを提供していないシステム／サービスを使うために非APIを使う技術が重要になる場合もある。
#（参考情報）ライブラリー形式の非API、#（参考情報）ライブラリとAPIも参照
詳細 > ライブラリとフレームワーク

APIはソフトウェアライブラリと対応しているのが一般的である。
APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。
1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。
広義のAPIはソフトウェアフレームワークと対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転や他の類似の機構によってフレームワーク側が流れを制御する。
詳細 > APIとプロトコル

APIはプロトコルの実装となっていることもある。
プロトコルは、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される。
APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMIは、JRMP（英語版）プロトコルまたはRMI-IIOPとしてのIIOPを実装している。
プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。
詳細 > APIとプロトコル > オブジェクトAPIとプロトコル

オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。
2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJavaで書かれたプログラムがC#で書かれたサービスをSOAPやIIOP経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。
一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリを使って複数プロセス間で行うこともあるし、タプルスペースのような共有技法を使うこともある。
ウェブAPI

→詳細は「Webサービス」を参照
ウェブAPIはHTTP要求メッセージ定義とJSON形式等の応答メッセージ定義で構成される。Web 2.0ではSOAPベースからRESTベースへと変化している。ウェブAPIはマッシュアップにより複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする。
ウェブAPI > ウェブによるコンテンツ共有

APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。
写真はFlickrやPhotobucketといったサイトからFacebookやMyspaceといったソーシャルネットワークサイトに共有される。
コンテンツは埋め込むこともできる。例えば、SlideShareにあるプレゼン資料をLinkedInのプロファイル情報に埋め込むことができる。
TwitterのつぶやきをFacebookの投稿にも同時に反映させるAPIもある。
動画コンテンツも別のホスト上のサイトに埋め込むことができる。
ウェブコミュニティにおけるユーザー情報を外部アプリケーションと共有させることができ、アプリケーションの更新をウェブ側から働きかけるなどの機能もオープンなAPIで実現されている。好例としてFacebookプラットフォーム（英語版）やOpenSocialプラットフォームがある。
ウェブAPI > 様式

WebAPIは様々なスタイルで表現される。例えばリソースの表現は以下の様式がありうる。
URLパス名: https://API.internal./japan/tokyo/sinjuku
URLクエリ文字列: https://API.internal./?country=japan&prefecture=tokyo&city=sinjuku
リクエストボディ: POST https://API.internal.   Body {country: japan, prefecture: tokyo, city: sinjuku}
パスは厳密な階層構造をもつリソースの表現に適している。クエリ文字列およびリクエストボディは自由な表現が可能なため任意のリソースに利用できる。
広く知られるWebAPIスタイルの例として以下が挙げられる。
RESTful API: 操作をHTTPメソッド、リソースをURLパス名で表現
GraphQL: 操作およびリソースをリクエストボディ内にDSL (GraphQL query language) で表現
SOAP
実装

POSIX標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOSやBSD系システムで実装されている。ただし、ABIや実行ファイル形式は標準化されていないため、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。
一方、APIおよびABIに互換性があるシステムならば、どこでも同じバイナリをそのまま実行可能である。これはアプリケーションソフトウェアベンダーにもユーザーにも有益であり、ベンダーは互換API/ABIが実装されていれば新システムが登場してもアプリケーション製品を修正・リビルドせずに済むし、ユーザーも古いソフトウェアを後方互換性のある新システムにインストールして利用できる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。
WindowsはAPI/ABIに後方互換性があり、例えばVisual C++とWindows SDKを使用して開発されたアプリケーションは、ビルド時にWindows APIヘッダーをインクルードする前にWINVERおよび_WIN32_WINNTなどのシンボルが適切に定義されていれば、指定したバージョン以降のすべてのWindowsで動作する。廃止されたAPI関数などを使用していない限り、アプリケーションを修正・リビルドする必要はない。新しいバージョンのWindowsで追加された機能を使いたい場合、WINVERおよび_WIN32_WINNTをそのバージョンに合わせて定義するか、LoadLibrary関数を使用して動的ロードする。
なおWindows XP以降では、特定のバージョンのWindowsの実装や内部仕様に依存するなど、誤った実装や後方互換性を無視した実装により正常に動作しなくなってしまったアプリケーション向けに、「互換モード」が用意されている。これはシステム側が返す情報を特定バージョンのWindowsのものに偽装することで、アプリケーションをだますことにより動作させる救済措置であり、本来はアプリケーション側をAPI外部仕様に基づいて正しく修正することが好ましい。
Unix系OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinuxではLinux Standard Baseがある。BSD系OSも各種あるが、互換性のレベルは様々である。
Androidには「APIレベル」という概念が存在し、Android OSのバージョンごとにAPIレベルの番号が割り振られている。例えばAndroid 10はAPIレベル29に相当する。特定のAPIレベルで追加された機能（クラス、メソッド、フィールド）を利用するには、アプリケーションのビルド時に "AndroidManifest.xml"あるいは "build.gradle"にてtargetSdkVersionの値をそのAPIレベル番号以降に設定し、また指定されたバージョン以降のAndroid SDKを使ってビルドする必要がある。また、minSdkVersionの値によって、アプリケーションのインストールおよび実行に必要な最小システムバージョンを指定することができる。minSdkVersion以下の機能は（廃止されたものでない限り）無条件で使用できるが、minSdkVersionを超えるバージョンで追加された機能を使用する場合は、android.os.Build.VERSION クラスのSDK_INTフィールドの値に基づいて動的分岐する処理を実装する必要がある。
APIの例

CarbonとCocoa - macOS
CORBA
Document Object Model (DOM) - HTML文書やXML文書をアプリケーションから利用するためのAPI
DirectX - Microsoft Windows用のマルチメディアAPI
EHLLAPI
iconv - 文字コード間の相互変換用API（POSIXの一部）
I/O Kit（英語版） - Darwin
Java API（英語版）
ODBC - Microsoft Windows
OpenAL - クロスプラットフォームのオーディオAPI
OpenCL - 異種計算資源を汎用並列処理に使用するためのクロスプラットフォームのAPI
OpenGL - クロスプラットフォームのグラフィックスAPI
OpenMP - クロスプラットフォームの共有メモリ型マルチプロセッシング用API。C/C++、Fortranで利用可能。
POSIX
QuickTime
Single UNIX Specification
Simple DirectMedia Layer (SDL)
Toolbox - Mac OS
Windows API - Microsoft Windows
XPCOM
EXtelligence API- EDIを組み込めるAPI
PicWish API- 画像加工API
VanceAI API- 画像拡大API
Image Enhancer
公開の方針

APIの公開に関しては2つの一般的な方針がある。
自社のAPIを厳重に秘匿する。
例えばソニーはライセンスをもった開発者にしかPlayStationの公開APIを利用できないようにしている。なぜならPlayStationのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、PlayStation用コンソールの販売を中止している。）[要出典]
自社のAPIを広く普及させる。
例えばマイクロソフトは計画的にAPIに関する情報を公開している。誰でも簡単にWindowsプラットフォーム用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。[要出典] OSなどのAPIは、いくつかのコードに分割され、ライブラリとして実装されており、OSと一緒に配布される。また直接アプリケーションの中に統合される必要があるAPIもある。
この2つの方針の中間もある。
APIと著作権の有無

2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを訴えた。Java APIを複製する許可（ライセンス）はOpenJDKプロジェクトやIBM J9などの実装には与えられていたが、一方AndroidのDalvik仮想マシンの実装はOpenJDKなどに基づいてはおらず、またGoogleはJava APIを複製する許可をとっていなかった。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年、最高裁によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した。ただしその後の審理を経て、2021年には著作権があってもフェアユースの下に利用可能であるとの判断が下されている。
日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている。
互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。
類似する概念

DDI (Device Driver Interface) - デバイスドライバを開発するためのソフトウェアインタフェース。WindowsおよびLinuxの用語。
SPI (System Programming Interface) -  アプリケーション構築用ではなくシステム制御や拡張用のインターフェース
ファームウェアインタフェース - ファームウェアを開発するためのソフトウェアインタフェース。UEFIなど。
ASPI - SCSI 装置を制御するためのソフトウェアインタフェース
特にDDIやファームウェアインタフェースを使う場合は、ソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。
言語束縛とインタフェースジェネレータ

複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。
以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。
SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）
F2PY: - FortranからPythonへのインタフェースジェネレータ