以上都講完了，可能有朋友沒有帶手機，沒有辦法連到Sli.do，有沒有現場想要討論或者是提出來的問題？
單一陳情系統就是非常好的例子，感謝主動提出來。
因為單一陳情系統，如果有人沒有用過的話，其實就是1999。那個單一陳情系統的特色是，以前是每個不同的陳情系統，其實不是為了API而開發的，所以會變成民間的第三方如果要接取的話，像小幫手之類的，就要必須爬那一個網友、猜那一些欄位的意思，然後虛擬一個瀏覽器按送出，如果廠商改一下，民間的API就爛掉了，以上不是廠商，最近就發生了（笑）。
這樣就增加大家的溝通成本，所以沒有好處，因此用一個大家都看得懂的API方式，用OAS的文件來說只要這樣接，保證不要亂掉，這樣就可以了，跟外面有一個讓彼此安心的合約概念。
所以未來任何陳請系統的欄位就不出這個，因此不管是陳請相似或者是相關的東西，都可以參照同樣的Schema，或甚至就是用完全同一份spec，關於噪音的陳請都可以來用同樣進線的KPI，只要自己配合的局處變多了，自然在這邊聲音就變大了，但不需要額外再寫文件或其他的東西，只要多一個報案的陳請類別就可以了，這是非常好的範例，非常感謝。
另外，剛才對於一開始想要解決什麼問題的範圍，還有這一份草案到底做什麼內容，希望能夠更具體做，因為反正有逐字稿，可以複製貼上上去，因此有比較好的說明方式，這個是非常具體的建議。
另外，等到未來用這種OAS方法建置出來的共通性API，真的對不特定人開放了，當然就會開始有執行的效率、資安及這位朋友問的會不會變成ddos的懶人包（對應 Sli.do：「openapi會不會變成ddos的懶人包？」）。
不過我想跟大家報告——我並不是做過這一種事，但是我朋友在做這一種事（笑）——他們絕對不是挑API，而是挑那一個網頁剛好看起來計算量最大，或者裡面有一些雜湊的東西，發現餵一些值進去，就可以讓它CPU飆高，絕對是挑那一些來打，而不是挑API來打。
API有一個攻擊表面跟防守表面，所以在測的時候，開六個API出來，其實把這六個防守好就沒事了，因為這整個系統對外的表面就這六個。
如果是透過網頁的話，尤其是透過一些可能還會被塞一些SQL沒有網頁程式的話，裡面就有雜湊、對撞而造成CPU過高預料的弱點，這一種攻擊表面非常非常大的。
這也就是為什麼剛剛所講的前後分離在資安上的好處，如果從伺服器的角度，從這六個表面出去，所有的介面都是在使用者的瀏覽器裡面或者是手機上面自己畫，即使打到了那個畫畫面的邏輯，只不過是把自己的CPU燒掉而已，跟你沒有關係，對你來講只要守住那六個API的標準就可以了，不用守透過這一個API建置出來不同服務的頁面，這是我們在資安管理上的好處。
我們不會列入想要解決的問題，因為是次發性的，也不是用API就不會被ddos，只是每次被ddos，然後每一次修好之後，每次要修的次數是可數的，也就是修好就是這六個，修好之後就不用再做別的事情了，但是舊的開發方式，也就是舊的廠商留下來某一個特定的網址，網頁裡面有個資，但是事實上下一手廠商不知道這一件事就被Google發現了，這一件事就會發生，大概是這樣子。
現場有沒有什麼問題？
第一：其實這一份是把本來的那一份，把本來那一份「資料存取」抬頭四個字拿掉的新版，但是舊的是直接merge新的，所以在那一份簡報裡面有很多「（舊版）」，意思就是我們沿用上一版。
意思是從我們的角度來看，並不是現在有兩個併行的規範，一個給人看、一個給機器看，而是我們把本來只給人看的規範，加了一個只給機器看所選用的段落變成新的規範，但是從舊的規範角度來看，其實是新版的概念，未來絕對不會有兩個合併的情況，是合併進新的規範。這樣可以嗎？
確實。因為OAS技術文件的中文翻譯老實說有完成一個草稿版，但因為中文翻譯的品質有非常大的精進空間，所以目前還在工作當中，最後是會有一個完整的部分。
我們也是在等下一個月中的核定板出來，才會說中文翻譯是定版，之前都是草稿版，這個確實是這樣。
本來是機關間開放資料集的整批互相交換，因此會寫到一些資料集整批互相的一些規範。這一些其實在新的裡面，其實所謂整批資料集互相交換，其實是OAS其中範圍之一，但是要交換的不是限於開放資料集了，甚至是需要登入、寫入跟log in的這一些東西都含括在裡面，因此當然在說明上會稍微抽象一些。但是我們覺得可以舉例，也就是在專業或者是專區上詳加說明的方式來因應。
接著應用範圍是寫「本規範適用於可將資料讀取或寫入應用程式介面」，為了使API具有共通性之特性，我想這裡的特性是「共通性之特性」的六字詮釋。從嚴解釋可以說沒有共通性或根本不需要共通性的API，我們都要讓它賦予共通性，也就是讓spec做到這一件事。
但這並不是我們的原意，我們的原意是如果API從你的角度來看，需要共通性，那本來就有共通性，這份文件是要適用、是有幫助的，但只要主觀判斷說其實沒有共通性或不需要共通性，這整份規範就不適用這一個服務，當時的利益是如此。
如果我們可以在說明當中說得更清楚、調整字樣的話，這沒有問題。原意是說共通性的內容是有好處，本來就有共通性，或者是下一版往共通性發展，來沿用這一份。
但是如果沒有共通性，像剛剛舉了一個很經典的例子，這兩個應用系統中間開Data base的view，這兩個系統中間完全是由SQL資料庫來控制，既沒有讓別人來接取，也絕對不會變成開放API，所以往機關內、機關外都沒有新的使用者，這個時候我們不會說共通性，絕對沒有共通性，這個時候絕對不會使用這個規範，這是很清楚的。
因此，我同意如果這樣寫的話，容易有兩、三種不同的讀法，因此至少在說明欄要寫清楚，這個我完全同意。
我快速綜整，範例這一個東西是非常好的具體建議，我們就這樣吧！畢竟會對Open Data到底多少筆有感的朋友，當然是很多，但比起公車有感的朋友來講，可能是九牛一毛或者是百分之一的數字，所以如果用PTX當範例的話，讓大家比較有感覺，而且也能夠比較細的demo一些運輸型態的這一些東西，利用到OAS裡面比較多的功能，這個是非常好的具體建議，我們就這樣做。
另外一個是網址列上，其實這邊的version，其實它是有語意的，也就是當你更新一個spec或者是更新軟體package的時候，其實API version是可以賦予語意的，你會常常看到這個spec是3.0.0，如果未來只是做一些字樣上的調整、修正的話，也就是改最右邊的數字3.0.1。
如果是增加，而不是減少，如果本來使用者不會爛掉，而加一些新功能，也就是3.1.0，如果本來正在用的使用者會爛掉，就一定要叫做4.0.0，也就是有所謂語意的版本。
我們在寫規範的時候，有一個問題是，公部門大家還是比較習慣V1、V2、V3、V4的感覺，所以我們才會說給機器看的，也許有一些語意，但從使用者的角度來看，也許是第二版至第五版而已，但第四、五版加欄位，第五、六版中間是修bug，這個部分人不太需要知道這一件事。
但是對外我們去改version的時候，其實通常有兩個可能性，也就是從裡面的角度來看，也就是讓本來的使用者不能再接取了，好比在改V2、V3的時候，會給V2一個日落期，好比有兩年的時間，但是從此之後，斜線V2就不再回覆了，就到V3來。
另外一個是，本來的API是某個廠商，新版的廠商是完全另外一個廠商，而新的廠商說得很清楚，沒有辦法再支援舊的廠商API，然後就被它說服了，這時也會有兩版併行的情況，就是舊系統還在運行，而新系統是加到V3這邊來，即使這兩個不是完全不相容，但只有V3這邊會加新功能，這個也是有可能的。
這個其實不是很容易表示，因此我們才會在這個上面說對外、對內是兩個不同的表示法，對內是機器可讀的表示法也許可以用別的方式，又或者在說明欄位加change log都可以，但畢竟是給開發者看的，如果這些資訊都塞到網址列的話，大家不一定都看得懂。
如果逐漸棄用某一版的時候就說V2變V3，V2什麼時候落入，或者是新舊兩個廠商，V2是不會落日的，但是只有V3會加新功能，V2、V3併行，這些都可以，但是如果只是內部調降什麼東西，OAS的文件會改，但外面看起來，一直還是在V1。這樣可以理解嗎？
Sli.do：「想請問之後會針對openapi提供中央標準規範嗎（如包含欄位需求，定義等等）？想確定是否要等中央標準，再且廠商設計API，以免格式不被沿用。」
這個是有兩個的回答，分別是技術上跟政治上的回答，這個工並不可能白做，即使你現在做了一個盤點，發現你目前所提供的JSON API的欄位名稱叫cars，中央領域的Schema訂出來叫做vehicles，所以這邊v1變成v2了，欄位需要調校。
但做調校的工作，本來手上這一份是讓他好做非常多的，因為就可以指明OAS說這個欄位要變成這一個欄位，或者是這個欄位本來是三個選項，但要變成四個選項之類的，你可以就事論事去要求它，生一份更動說明書的時候，會錯意的機率非常低。
但是現在如果不做這一個盤點，等到另外一個領域的Schema下來的時候，那你要重新對齊，那是從頭做。
我的意思是我們把它想成是繞路好了，現在即使先做，並沒有真的繞遠路，而是在去的路上，可能不只十五度角，不會變成白做，而又要繞回去，會稍微繞一點，但我說整體來講是往整體的程序來走，這個是技術上的回答。
在政治上的回答是，當然國發會現在對於各種不同的領域，會定義這一個領域相關的資料集綱要，但是這一些資料綱要要如何訂？就是是看現在有誰已經把它做得還不錯了，跟別的利益關係人討論支援這個會不會有困難，所以越早做到這一個，就越有可能影響最後的即時大家要共通性的綱要，你越先做、要改的幅度就越小，是別人來抄你，並不是別人來抄你，我不會說每一個領域都是這樣，我也不是這樣的意思，而是有這一件事出現的話，現在先做比較有好處。
Sli.do：「今天所講的都是api的「說明文件」？」
你本來用什麼工具就用什麼工具，完全並沒有干擾你設計API的事情，這個是彼此不同的廠商、開發者非常好用的工具，但是內部要如何生出這一份東西來，完全是沒有規範的，因此這一件事，我覺得應該不會造成太大的負擔，只要不要把它寫成KPI。
有沒有其他想要討論的問題？一次、二次、三次，如果沒有的話，就非常感謝大家，有任何問題就讓國發會知道，謝謝大家。
今天很謝謝大家，不好意思，讓大家等了一下，我們今天其實主要是把大家手上各自有的資料跟一些規劃讓彼此知道，就是彼此先知情的會議，我們先從哪一個部會開始？
在民航局之前，有沒有任何人對於簡報內容要詢問的？
多一隊要三種人嗎？就是保護維護的人要兩至三年訓練？包含地勤的人員要想辦法找到廠商及飛行員，飛行員目前的飛機已經在換了，所以其實就是慢慢會變成黑鷹，黑鷹之後駐地總數是要減少，而不是要增加的，我剛剛聽到的訊息是這樣子。
所以如果要特別增加駐地的話，除非這三種編組都想辦法找到錢，不然其實是做不到，是這個意思嗎？
連江縣委由民航，所以開了一個標出去，那一個具體實際的做法也是會有這三種人，包含飛行員、飛機及地勤，那個標裡面都涵蓋？
瞭解，謝謝。
是不是也受天候的影響？
所以運氣不好，飛不起來？
如果最後真的做的話，就是特別用抗測能力強來飛，不然一年可能沒有幾天飛得起來？
所以4至10月任何機型都可以飛，也沒有限航區的問題？
