@vrkr Ma swoje plusy - jest to format Excelowy, a klienci nietechniczni lubią Excele. Można lubić albo nie lubić, dane będziesz dostawal w tabelkach

@serel jest tyle standardów, że głowa boli... Zróbmy zatem kolejny, ale taki, który połączy zalety wszystkich standardów, i będzie standardem ostatecznym!

@ZohanTSW zróbmy dla beki format który zatem połączy wady wszystkich standardów, ale z jakiegoś dziwnego powodu się przyjmie, bo ci którzy z niego korzystali, dla beki będą go polecać innym.

@dziad_saksonski i obsłudze typu zmiennej też

@dziad_saksonski Oj tam, oj tam

@dziad_saksonski lol, nie mozecie w normalnej bieliznie pracowac?

@bartek555 nie no co ty, kazdy szanujący się zdalny pracownik siedzi w szlafroku z piwerkiem

@dziad_saksonski no to ok, ale te stringi to troche imo przesada

@GazelkaFarelka Wszystko zależy co chcesz wysyłać, w jaki sposób i ile. No i czy ktoś nie będzie musiał tego czytać potem przy debugowaniu XD

@Czokowoko Tu jest porównanie z json więc wymyśliłam jak dołożyć do tego po prawej zalety jsona a jednocześnie utrzymać większą kompaktowość danych, którą daje format po prawej. Oczywiście zakładaǰac, że przekazujemy dużą ilość danych (wtedy te zyski na kB mają znaczenie), a wszystkie elementy mają tą samą strukturę. Można każdy element dawać nawet w nowej linii, dzieki czemu można by odczytywać i przetwarzać linia po linii, zamiast wczytywania najpierw całości do pamięci, co ma znaczenie przy bardzo dużych plikach.

@GazelkaFarelka bullshit. Żołnierz jak potrzebujesz miejsca i tyle. To gówno wymaga deklaracji, więc wymaga w cholerę zmian w których łatwo o błędy, przedwczesna optymalizacja to źródło wszelkiego zla

@baklazan Nie rozumiem zarzutów, w każdym formacie można zrobić błędy. W mojej propozycji jest o tyle lepiej, że jeżeli odczytany wiersz nie pasuje do podanej w headerze struktury to go odrzucasz w przetwarzaniu - nie wywala ci po zaciagnięciu i załadowaniu do pamięci całego 3 GB pliku "json parse error", bo gdzieś tam ktoś nie escapował delimitera.

@GazelkaFarelka pytanie ile realnie na realnych danych to oszczędza, uwzględniając kompresję, jakiegoś bieda gzipa, nie mówiąc o brotli

Do tego jak wygląda zagnieżdżanie? Gdzie typy? Czy to działa tylko dla płaskiej "struktury" w której wszystko jest stringiem?

@GazelkaFarelka Przeca jsona nie używa się po to żeby zaoszczędzić miejsce tylko po to żeby dobrze się go czytało oczami. Ten TOON nawet w przykładzie to padaka bo trzeba co chwila zerkać do headera, przy większej ilości tekstu równie dobrze można trzymać te dane w jakimś binarnym formacie który pewnie i tak byłby bardziej czytelny niż to xd

@dzek kompresję masz tak czy siak, tu i tu, a realnie ile oszczędzisz zależy od wielkości danych w wierszu, to czysty tekst więc bardzo łatwo policzyć dla konkretnego zestawu danych

@megawonsz9 Co? Json jest po to, żeby zakodować wielowymiarowe dane o dowolnej strukturze. Owszem, lepiej się to czyta i jest idealne do wymiany relatywnie niewielkich porcji danych. Jeżeli jednak masz dane, które są monstrualne, gdzie struktura każdego rekordu jest identyczna, to można pominąć deklarowanie jej w de facto każdym elemencie. Z tym, że wadą CSV jest płaski wymiar i brak możliwości określenia typów danych.

Ogólnie wymiana danych polegająca na przetwarzaniu plików to kupa

@GazelkaFarelka Obrazek porównuje z JSON, ale ja porównuje z CSV.

@GazelkaFarelka OMG, słownik... "Żołnierz" - miało być zipujesz.

Chodzi mi o to że celem tego formatu jest ograniczenie powtórzeń kluczy w celu zmniejszenia pliku. Tyle że tym się zajmują algorytmy kompresji, z automatu, bez ludzkiej ingerencji.

Dlaczego zrzucać sprawdzanie błędów semantycznych na parser? Siłą JSONa jest to że jest taki jak go zinterpretujesz, parser ma minimalne wymagania co do pliku, tak, możesz zgubić cudzysłów, ale równie dobrze w Twoim możesz zgubić przecinek, albo może Ci wpaść jeden ekstra, masz ten sam problem.

@baklazan Przecież oba formaty możesz dodatkowo tak samo skompresować, co to za argument.

Różnica jest taka, że jak masz format możliwy do odczytywania porcjami, na przykład linia po linii, to na np. trzy miliony rekordów błąd parsowania w jednej linii nie rozwali ci całego odczytu pliku. Przetworzysz sobie poprawnie 2 999 999 wierszy danych, a ten jeden wadliwy rekord zaraportujesz jako błąd.

@Ragnarokk Tzn zgadzam się z tym, że ten toon jest to dosłownie CSV - niczym się w ogóle od niego nie różni. Ale rozumiem zamysł za tym stojący. Dlatego zaproponowałam moje rozwiązanie, które zmniejsza rozmiar pliku w podobny sposób, a jednocześnie jest nieco lepsze niż toon i CSV, bo eliminuje jego pewne wady.

Miałbyś header w tym stylu - gdzie deklarujesz typy, strukturę wiersza, pozwalającą też na zagnieżdżone struktury:

{"firstname": string, "lastname": string, "birthday": date, "father": {"firstname": string, "lastname": string}, "mother": {"firstname": string, "lastname": string}, children: {"firstname": string, "lastname": string}}

Oraz dane (każdy w osobnej linii)

{"Jan","Kowalski","1967-05-12",{"Wacław","Kowalski"},{"Janina","Kowalska"},[{"Zofia","Kowalska"}, {"Antoni","Kowalski"}]}

Dostajesz ten sam zysk to w toon i csv (oszczędzony rozmiar pliku na kluczach - no, nie dokładnie ten sam, u mnie jest odrobinę więcej bo są klamry i delimitery), a jednocześnie możliwość zapisywania bardziej złożonej struktury danych niż flat oddzielony przecinkami, a w przypadku danych w relacji jeden do wielu, konieczności zrzucania tego do dwóch osobnych plików (na moim przykładzie jakby to był csv, to musiałbyś zrobić dwa pliki - people.csv i children.csv i nie miałbyś dostępu do wiedzy o childrenach przetwarzając people.csv)

Przecież oba formaty możesz dodatkowo tak samo skompresować, co to za argument.

@GazelkaFarelka Przepraszam najmocniej, ale dalej nie rozumiesz. Toon próbuje oszczędzać wielkość pliku, poprzez skomplikowanie składni (wymaga parsowania semantyki! prostej bo prostej, ale wciąż! Wprowadza prosty system typów!), podczas gdy można skompresować JSONa i osiągnąć nawet lepsze wyniki niż Toon. Po kompresji, oba powinny mieć marginalnie podobne wielkości. Więc pytanie: po co Ci to?

> Różnica jest taka, że jak masz format możliwy do odczytywania porcjami, na przykład linia po linii, to na np. trzy miliony rekordów błąd parsowania w jednej linii nie rozwali ci całego odczytu pliku.

To jest akurat bzdura: JSONa da się recoverować, brak `}` albo `"` jest do naprawienia przy tak samo prostej strukturze jaką obsługuje Toon więc jaki problem tak naprawdę rozwiązuje?

@Eruanno No to najwyraźniej nie wszyscy

@Catharsis Fajnie, wciąż to CSV with extra step

To nie hejt, hejt jest zarezerwowany na XMLa

@Ragnarokk 

wciąż to CSV with extra step

No ale dokładnie to napisali twórcy w podlinkowanym readme. Ten format jest lekko większy niż CSV ale pozwala na lepsze i dokładniejsze przekazanie informacji do modelu. Tam jest podane parę testów i benchmarków i w większości modele lepiej sobie radzą z odczytem danych w TOON niż CSV. Minimalnie ale jednak lepiej więc nie jest to bezsensowne.

A XML to wiadomo xD

@Catharsis To tylko kręcenie beki z vibe coderów którzy wymyślają koło na nowo, prosze nie mieszać pojęć ( ͡° ͜ʖ ͡°)