我現在看不出來。
我的意思是說，如果真的要推OAS 3的話，我就回到我的目標，剛剛一直講到品質、實際狀況及使用者需求，我可以用嗎？
……其實沒有針對每一塊更詳細定義，為什麼日期要用ISO 8601，有沒有其他的方式？
那目前推出來沒有啊！
因此這個東西應該要回過頭來定義到這個層次的時候，我們可以往前推了。在這裡面也會發現有這樣要求嗎？
因此我覺得應該要拉開來，我當然很想要所有的東西回到層次裡面去定義，這邊所有的定義，每一個欄位都是用Schema定義出來，我發現日期全部還不是用ISO 8601的格式，因為有的還沒有寫。這時我要怎麼辦？
我意思是說把OAS 3往前拉回來，拉回來叫他們說這個東西要重新定義，他們花很多時間來做這一件事，也就是問圖的路徑要不要全部寫出來，他們是在做這一件事，但是這並不是因為他們轉成Swagger才會產生的事情，而是發現使用的時候，發現完全不合格，因此才會去談。
我的意思是，你現在改的還是文字上的tune而已，但是又拉回到票價的表格整個都要調整，那就不是只定義這一個東西而已。
是原本系統資料產出的時候就有問題。
我完全不知道普通車叫做對號（車），我完全不知道，我的意思是原始的東西寫得很爛，你裝在叫做格式化、結構化的東西，還是長得很爛，你可以回過頭來跟台鐵說：「真的很糟糕，是不是要重寫？」
沒有，區間車裡面沒有電聯車，在票價裡面沒有定義這個東西！我看過了，沒有！有自強號、復興號、莒光號及普通車，但是沒有區間車、電聯車。
……所以一般使用車來講只知道區間車啊！在賣票的時候用普通車來定義我的票價用普通車。
看台鐵好了，普通車是什麼意思？是區間車還是莒光號還是什麼？普通車是什麼意思？
可是我的重點已經在這邊，現在已經走了Swagger，很清楚是要用自動化都可以做，但是問題是裡面任何一條定義……
API的操作手冊，現在只講那一塊而已，但是我們已經往前一直走，所以我說要幫唐鳳拉回來。
我不是說做得怎麼樣，但是花了很大的功夫，因為我去交通部，所以最值得他們是政府來參考及學習的，他們的描述很多都是很糟糕的，但是原始就很糟糕了，並不是你們變糟糕。因此問題就來了，如果把OAS 3推出來之後會比較好用嗎？
對！重點在這裡！我們的手冊管理是真的很爛，是定義很爛，而不是格式很爛啊！
但是這裡有一個很大的問題是手冊描寫夠好嗎？
大家有沒有發現，我們現在講的東西已經跳脫OAS要定義的東西，已經往前一直拉了，不管是API的建置也好，或者是前面講到資料的定義也好，可是OAS 3是在處理最後一塊，對我來講就是文件整理而已，叫做一個JSON的格式出來而已。
要反過來幫OAS講話。
是的。
就像我剛剛所講的，Open API的組織就是這兩個字，因此再如何澄清都沒有用，從目標端講清楚就夠了。
我其實滿想知道的事情是，是不是能夠有清楚的目標？並不是只有交換而已，而是真的往所謂的到底往哪裡走？以及在這裡面所扮演的角色是什麼？
我們講API好了，講information model的時候，就是把後面的東西很清楚，但如果像data.gov.tw網站上那一堆叫做爛資料東西的時候，Open API要如何扮演角色？及如何協助？從目標端回過來講，我推這個東西的目的，這樣才可以很清楚步驟、方向及要求。
另外，政府端應用的時候，我覺得現在最大的問題是不是在API這一塊，而是讀出來的資料到底會如何使用？
……我的意思是，從應用面回來推目標跟目的，因為我們現在看到有一個東西叫做OpenAPI，這是規範，我們從規範這邊來推的時候，的確是規範，我們就按照制度走就好了，但是到底要走到哪裡去？絕對不能跟OpenAPI綁在一起談，我們有成千上百萬自動化處理，開放者需要處理這麼多的API嗎？如果有需要用的時候，我們會拉過來用。
真的嗎？
剛剛Ronny說這是應用規範的說明，我很好奇的是，我們會有上千萬個API自動化處理嗎？
PTX其實可以用付費方式來收費的時候，不一定要用Open API，可以發現這裡面接資料端的時候，其實跟Open Data完全脫鉤的關係。
不一定啊！如果今天是環保署或者是文化部的API要經過註冊的時候使用的，可以在裡面不一定要放Open API，可以選擇這樣的模式來運作。
尤其政委一開始就說這個是開放資料的下一步。
不管怎麼推，大家會回過頭來看文件描述的時候，會問這個跟Open Data的關係是什麼。
其實剛剛一直講到這跟Open API結合，所以這根本沒有結合，所以我附議剛剛講的，用Open API來形容是不恰當的，但是我還是會回過來質疑本來叫做OpenAPI，或者是叫OAS 3，大家回去找的時候還是會回過來找，還是會找到OpenAPI這個字，如果是同一個字或者是分開的字，Open API這個組織是分開的兩個字，並不是同一個字。
