+1 (non-binding) On Thu, Jan 18, 2024, 22:51 Scheffler Jens (XC-AS/EAE-ADA-T) <jens.scheff...@de.bosch.com.invalid> wrote:
> +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 >