+1 binding as discussed - looking forward for this and THANKS! Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Tzu-ping Chung <t...@astronomer.io.INVALID> Sent: Thursday, January 18, 2024 9:07:42 AM To: dev@airflow.apache.org <dev@airflow.apache.org> Subject: [VOTE] Accept AIP-60 (Standard URI representation for Airflow Datasets)
AIP page: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FAIRFLOW%2FAIP-60%2BStandard%2BURI%2Brepresentation%2Bfor%2BAirflow%2BDatasets&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7Cfeb80ec5aa4b4fa99c7a08dc17fc9ae4%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638411620901637967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZJ3XtYmB5k5NsO%2Ft%2F05QSxH9CIrYEiP4td09LZZ8rcI%3D&reserved=0<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-60+Standard+URI+representation+for+Airflow+Datasets> Discussion thread: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Frf6c80ljjkml0l15h2jys7k713q3os1d&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7Cfeb80ec5aa4b4fa99c7a08dc17fc9ae4%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638411620901637967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QQqR1gaRDfC9udbGbMubPfkyt73jSUmB7uPU%2BukCE2s%3D&reserved=0<https://lists.apache.org/thread/rf6c80ljjkml0l15h2jys7k713q3os1d> Reaction on the proposal seems to mostly positive, with most comments around what documentation should be added, and the exact criteria the AIP should be considered “done”. I believe I have addressed most of them; most notably, additional sentences have been added to the What defines this AIP as "done"? section to require the best practice to be demonstrated by example DAGs and tutorials in the documentation. One comment I left unaddressed is about auto-generating documentation from providers. This is mostly because I’m not quite sure how it can be practical. We can generate a list of supported protocols (s3, gcs, file, etc.), but that is not particularly useful to users without the actual format the URI would use. In the current implementation, each URI handler is a simple Python function, and it is not viable to extract logic from it unless we adopt some kind of rule-based parser (like regex, and even that is too complex to automatically generate documentation from). I am open to suggestions on this, so feel free to give a -1 with an idea on this. Otherwise I would move the proposal forward without auto documentation generation. This vote will be kept open for more than 72 hours even if three +1s are reached, to gather potential ideas on the documentation thing mentioned above. I intend to start implementation (including the example DAGs) in the mean time. TP
