Jak w temacie. Są różne modele przetwarzania dokumentów XML.
Korzystał ktoś z parserów bazujących na VTD? Jeśli tak to dlaczgo taki wybór? Jakaś kolosalna różnica wydajności przy przetwarzaniu VTD vs SAX? Inne?
0
1
Z tego co widzę to VTD ma na zadanie trzymanie struktury XMLa w pamięci (tak jak DOM) w taki sposób, żeby było to lekkie. Pewnie ma to sens, jak chcesz wyciągnąć coś skomplikowanego z XMLa, gdy SAX nie jest wygodny (bo musisz sam implementować kontekst zamiast zrobić parę ifów na sparsowanych danych) a DOM jest za ciężki, bo tworzenie normalnego obiektu do każdego elementu zbyt mocno obciąża zasoby.
Nie zmienia to faktu, że dzisiaj wystarczy użyć jakiegoś normalnego formatu. Po latach dominacji ludzkość odkryła, że XML jest zarówno nieczytelny dla ludzi jak i maszyn i nie warto brnąć dalej w ten archaiczny format
1
Nie zmienia to faktu, że dzisiaj wystarczy użyć jakiegoś normalnego formatu. Po latach dominacji ludzkość odkryła, że XML jest zarówno nieczytelny dla ludzi jak i maszyn i nie warto brnąć dalej w ten archaiczny format
XML nie jest bardziej nieczytelny niż JSON a ma przy tym więcej możliwości. JSON się upowszechnił, bo to naturalny sposób zapisu obiektów z JS, a że JS jest we froncie, to normalne, że jest to standardowy rodzaj transportu danych.
1
@.andy: więcej możliwości to wolniejsze parsowanie czy doktoryzowanie się na temat ficzerów, których nikt nie używa ale przynajmniej ktoś może nam zabić serwer albo wykraść dane. Do tego problemy z mapowaniem pomiędzy strukturami używanymi w językach programowania a XMLem np. jak mapować pola (atrybuty czy nody) albo brak standardowego sposobu na przedstawienie listy. Do tego cały burdel z namespacami, różnymi standardami i toolami, które musisz znać nawet jak nie chcesz. JSON z drugiej strony na samym początku zabronił komentarze, bo autor wiedział, że będą używane jako metadane. Nie wyobrażam sobie, żeby ktoś w 2022 roku powiedział: "XML to jest to czego nam potrzeba"
1
więcej możliwości to wolniejsze parsowanie czy doktoryzowanie się na temat ficzerów, których nikt nie używa
A masz jakieś dowody, że nowoczesne parsery XML są o wiele bardziej wolniejsze niż JSON? ;)
Druga kwestia. Widziałeś gdzieś użycie JSON jako format wymiany dokumentów elektronicznych? Np. EDI?
Do tego problemy z mapowaniem pomiędzy strukturami używanymi w językach programowania a XMLem np. jak mapować pola (atrybuty czy nody) albo brak standardowego sposobu na przedstawienie listy.
Ale co t oznaczy standardowego?
Przykład https://xmpp.org/extensions/xep-0167.html
<iq from='[email protected]/orchard'
id='ih28sx61'
to='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='[email protected]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<payload-type id='0' name='PCMU'/>
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<candidate component='1'
foundation='1'
generation='0'
id='el0747fg11'
ip='10.0.1.1'
network='1'
port='8998'
priority='2130706431'
protocol='udp'
type='host'/>
<candidate component='1'
foundation='2'
generation='0'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45664'
priority='1694498815'
protocol='udp'
rel-addr='10.0.1.1'
rel-port='8998'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
Masz listę różnych kodeków, które są wysyłane przy inicjalizacji sesji audio.
Do tego cały burdel z namespacami, różnymi standardami i toolami, które musisz znać nawet jak nie chcesz.
No ale nie rozumiem. Chcesz obsłużyć dokumenty elektroniczne i patrzysz na schemat, potem robisz parsowanie. W czym problem?
JSON z drugiej strony na samym początku zabronił komentarze, bo autor wiedział, że będą używane jako metadane. Nie wyobrażam sobie, żeby ktoś w 2022 roku powiedział: "XML to jest to czego nam potrzeba"
Jak każda technologia ma swoje plusy i minusy. Nie twierdzę, że XML jest idealny dla każdego rozwiązania. Tak samo zresztą jak JSON. Złe jest wrzucanie danej technologii tam gdzie się nie nadaje - przykład? Pakowanie wszędzie dzisiaj blokczajna, bo jest sexy :D
1
@.andy:
A masz jakieś dowody, że nowoczesne parsery XML są o wiele bardziej wolniejsze niż JSON? ;)
kiedyś (parę lat temu) rozwijałem system, który musiał bardzo szybko parsować XMLe. W porównaniu do "szybkich" bibliotek do parsowania JSONa wydajność była kilkukrotnie niższa. Np. ta ( http://rapidxml.sourceforge.net/manual.html ) biblioteka jest całkiem szybka, ale tu wychodzi inny problem: wybierasz albo szybkość albo ficzery, z JSONem nie masz takich problemów, bo ficzerów jest mało i każda biblioteka wspiera wszystko. Z innej strony to parsowanie JSONów teraz jest tak szybkie ( https://github.com/simdjson/simdjson ), że w większości przypadków dużo większym bottleneckiem jest alokacja pamięci i interpretowanie struktury dokumentu niż samo parsowanie.
Druga kwestia. Widziałeś gdzieś użycie JSON jako format wymiany dokumentów elektronicznych? Np. EDI?
nie/nie wiem. Tak samo listy z sądu przychodzą pocztą tradycyjną a nie mailem, bo tak się przyjęło i taka była moda/możliwości
Ale co t oznaczy standardowego?
że w dowolnym języku zrobię odpowiednik pythonowego json.loads i bez znajomości struktury wiem gdzie mam listę a gdzie nie i mogę coś z nią zrobić np. zwijać wszystkie elementy w przeglądarce logów czy modyfikować coś ad hoc. XML natomiast rodzi takie dyskusje https://stackoverflow.com/questions/449020/how-should-a-list-be-represented-in-xml
No ale nie rozumiem. Chcesz obsłużyć dokumenty elektroniczne i patrzysz na schemat, potem robisz parsowanie. W czym problem?
To może nie problem samego XMLa tylko otoczki i standardów. Największy problem jaki widzę, to mocne połączenie schemy z dokumentem. JSON schema działa jako całkowicie osobny byt: mogę jej używać ale nie muszę. Z drugiej strony dokumenty XMLa same w sobie mówią do jakiej schemy należą co rodzi problemy, bo niektóre parsery odmawiają parsowania jak nie podam schemy albo wykładają się jak schema jest w użyciu
Pakowanie wszędzie dzisiaj blokczajna, bo jest sexy :D
Tutaj akurat muszę przyznać, że XML wychodzi lepiej
0
kiedyś (parę lat temu) rozwijałem system, który musiał bardzo szybko parsować XMLe. W porównaniu do "szybkich" bibliotek do parsowania JSONa wydajność była kilkukrotnie niższa.
Z chęcią chciałbym zobaczyć te porównania na dzień dzisiejszy. Z jednym się zgodzę.Ze względu na większe możliwości czas przetwarzania może być nieznacznie większy. No i są różne tryby przetwarzania XMLi - wszystko zależy od potrzeb.
Druga kwestia. Widziałeś gdzieś użycie JSON jako format wymiany dokumentów elektronicznych? Np. EDI?
nie/nie wiem. Tak samo listy z sądu przychodzą pocztą tradycyjną a nie mailem, bo tak się przyjęło i taka była moda/możliwości
No właśnie. Ja osobiście nie widziałem takich dokumentów. Nie twierdzę, że JSON jest zły i nie należy go używać, jednak w wielu obszarach XML go plaskaczem załatwia :P ;)
że w dowolnym języku zrobię odpowiednik pythonowego json.loads i bez znajomości struktury wiem gdzie mam listę a gdzie nie i mogę coś z nią zrobić np. zwijać wszystkie elementy w przeglądarce logów czy modyfikować coś ad hoc. XML natomiast rodzi takie dyskusje https://stackoverflow.com/que[...]-a-list-be-represented-in-xml
Z tą listą to tak na siłę trochę ;)
To może nie problem samego XMLa tylko otoczki i standardów. Największy problem jaki widzę, to mocne połączenie schemy z dokumentem. JSON schema działa jako całkowicie osobny byt: mogę jej używać ale nie muszę. Z drugiej strony dokumenty XMLa same w sobie mówią do jakiej schemy należą co rodzi problemy, bo niektóre parsery odmawiają parsowania jak nie podam schemy albo wykładają się jak schema jest w użyciu
Moim skromnym zdaniem XML idealnie się sprawdza do wymiany dokumentów elektronicznych.
BTW, XMPP stoi na XMLu. Wiele osób zarzuca, że to wada ale dla mnie to właśnie zaleta. Zobacz, dla beki powstał kiedyś XEP, który miał pokazać użycie JSONa zamiast XMLa https://xmpp.org/extensions/xep-0295.html.
Jak dla mnie i JSON i XML ma swoje obszary gdzie się sprawdzi i należy tam go używać a nie na siłę pchać tylko coś bo jest nowe i sexy - ala blockchain.
0
Tak tylko wtrącę, że koncepcja VTD może być użyta nie tylko do XML, ale również do YAML czy JSON. Dokument ładowany jest do pamięci (nie ma znaczenia, czy to XML/JSON/YAML, inny), do tego budowany jest indeks wskazujący na tokeny w dokumencie i przy wykorzystaniue tego indeksu możliwe jest wydajne nawigowanie po strukturze. Przynajmniej tak zrozumiałem ideę VTD.
Z tego co doczytywałem, to implementacje (jedna? :)) VTD XML mają dodatkowe ograniczenia, np. nie wspierają całej specyfikacji XML, więc przy złożonych dokumentach można spodziewać się niespodzianek. Daty publikacji nt. VTD wskazują, że temat chyba dawno umarł śmiercią naturalną.
1
@yarel: zgaduję, że nikt tego tak na prawdę nie potrzebował + autor najprawdopodobniej kłamie. Nie da się sparsować XMLa w taki sposób, żeby same odnośniki do dokumentu wystarczyły. A co z escape characters albo CDATA? RapidJSON pozwala na tą technikę https://rapidjson.org/md_doc_dom.html#InSituParsing , która modyfikuje wejściowy dokument w celu użycia właśnie takich odnośników do wejściowego dokumentu. Jeżeli to ma polegać na kolejnym parsowaniu w czasie czytania tego VTD to mówi o nie pełnym parsowaniu, bo po to parsuję dokument, żeby nie bawić się w takie pierdoły
0
Nie wiem czy autor kłamie czy nie, natomiast niektórzy potrzebują szybkiego przetwarzania dokumentów XML i nie wszystkich możliwych, a o określonej strukturze, więc ograniczenia modelu przetwarzania mogą być akcepowalne i pożądane np. ze względu na zyski wydajnościowe, czy prostsze API.
Nie da się sparsować XMLa w taki sposób, żeby same odnośniki do dokumentu wystarczyły.
Co masz na myśli pisząc o wystarczalności odnośników?
np. prosty dokument
<doc>
<foo bar="1"/>
<foo bar="2"/>
<foo bar="3"/>
<doc>
+ prosty indeks: <foo -> [ (offset=10, len=4, depth=1), (offset=28, len=4, depth=1), (offset=46, len=4, depth=1)] można łatwo w pamięci przeskakiwać do elementów "//foo" o poziomie zagnieżdżenia=1. To tylko taki uproszczony indeks, bo na poziomie implementacji jest zapewne bardziej złożone (np. umożliwia przejście na określony poziom zagnieżdżenia i parsowanie w głąb od tego wybranego miejsca) albo zrzucone na "brak pełnego wsparcia dla specyfikacji XML" :-)
0
Co masz na myśli pisząc o wystarczalności odnośników?
<doc>"hello"</doc>
Oczekiwałbym, że dostanę "hello" a nie coś pośredniego, ostatecznie muszę zrobić kolejne parsowanie w czasie czytania wartości. Do tego na pewno dochodzi analogiczny problem z CDATA.
0
Jak dla mnie i JSON i XML ma swoje obszary gdzie się sprawdzi i należy tam go używać a nie na siłę pchać tylko coś bo jest nowe i sexy - ala blockchain.
@.andy: i tu jest problem, bo ja zalet XMLa nie widzę poza po co ruszać jak działa z czym się zgadzam. Wszystkie obszary, które opisałeś używają XMLa, bo był wtedy modny i tyle. Mi chodzi o taką sytuację, że ktoś w 2022 roku uzna, że chce użyć XMLa w nowym API pomiędzy serwisami (więc argument z webem odpada). Po prostu nie potrafię sobie tego wyobrazić