VTD-XML

VTD-XML

Utvecklare	XimpleWare
Stabil frisättning	2.13_4 / 14 juli 2017 ( 2017-07-14 )
Operativ system	Bärbar
Plattform	Java, C#, C och C++
Typ	XML parser/indexer/slicer/editor -bibliotek
Licens	GPL och proprietär licens
Hemsida	vtd-xml .sourceforge .io ximpleware .wordpress .com

Virtual Token Descriptor for eXtensible Markup Language ( VTD-XML ) hänvisar till en samling plattformsoberoende XML- behandlingsteknologier centrerade på en icke-extraktiv XML , "dokumentcentrerad" analysteknik som kallas Virtual Token Descriptor (VTD). Beroende på perspektivet kan VTD-XML ses som något av följande:

• En " dokumentcentrerad " XML- tolkare
• En inbyggd XML- indexerare eller ett filformat som använder binär data för att förbättra text-XML
• En inkrementell XML-innehållsmodifierare
• En XML slicer/splitter/assembler
• En XML-redigerare/radergummi
• Ett sätt att porta XML-bearbetning på chip
• En icke-blockerande, tillståndslös XPath- utvärderare

VTD-XML är utvecklad av XimpleWare och dubbellicensierad under GPL och egen licens. Det är ursprungligen skrivet i Java , men är nu tillgängligt i C , C++ och C# .

Grundläggande koncept

Icke-extraktiv, dokumentcentrerad analys

Traditionellt representerar en lexikalanalysator tokens (de små enheterna av odelbara teckenvärden) som diskreta strängobjekt. Detta tillvägagångssätt betecknas extraktiv analys. Däremot icke-extraktiv tokenisering att man håller källtexten intakt och använder förskjutningar och längder för att beskriva dessa tokens.

Virtuell token-beskrivning

Virtual Token Descriptor ( VTD ) tillämpar konceptet med icke-extraktiv, dokumentcentrerad analys på XML-bearbetning. En VTD-post använder ett 64-bitars heltal för att koda offset, längd, tokentyp och kapslingsdjup för en token i ett XML-dokument. Eftersom alla VTD-poster är 64 bitar långa kan de lagras effektivt och hanteras som en array.

Platscache

Platscacher ( LC ) bygger på VTD-poster för att ge effektiv direktåtkomst. Organiserade som tabeller, med en tabell per kapslingsdjupnivå, innehåller LC:er poster som modellerar ett XML-dokuments elementhierarki. En LC-post är ett 64-bitars heltal som kodar ett par 32-bitars värden. De övre 32 bitarna identifierar VTD-posten för motsvarande element. De lägre 32 bitarna identifierar elementets första barn i LC på nästa lägre kapslingsnivå.

Fördelar

Översikt

Praktiskt taget alla kärnfördelarna med VTD-XML är inneboende i icke-extraktiv, dokumentcentrerad analys som ger dessa egenskaper:

• XML-källtexten hålls intakt i minnet utan avkodning.
• Den interna representationen av VTD-XML är i sig beständig .
• Undviker objektorienterad modellering av den hierarkiska representationen eftersom den helt och hållet förlitar sig på primitiva datatyper (t.ex. 64-bitars heltal) för att representera XML-hierarkin, vilket minskar kostnaden för att skapa objekt till nästan noll.

Genom att kombinera dessa egenskaper kan man tänka på XML enbart som syntax (bitar, byte, förskjutningar, längder, fragment, namnområdeskompenserade fragment och dokumentsammansättning) istället för serialisering/deserialisering av objekt. Detta är ett kraftfullt sätt att tänka på XML/ SOA -applikationer.

Överensstämmelse

VTD-XML överensstämmer strikt med XML 1.0 (förutom DTD-delen) och XML Namespace 1.0. Den överensstämmer i huvudsak med XPath 1.0-specifikationen (med några subtila skillnader när det gäller underliggande datamodell) med tillägg till XPath 2.0 inbyggda funktioner.

Enkelhet

Som parser

När VTD-XML används i parsningsläge är en XML-parser med extremt hög prestanda för allmänt bruk som kan jämföras med andra:

• VTD-XML överträffar vanligtvis SAX (med NULL-innehållshanterare) samtidigt som det ger full slumpmässig åtkomst och inbyggt XPath -stöd.
• VTD-XML förbrukar vanligtvis 1,3-1,5 gånger XML-dokumentets storlek i minnet, vilket är ungefär 1/5 av minnesanvändningen för DOM [
• Applikationer skrivna i VTD-XML är vanligtvis mycket kortare och renare än deras DOM- eller SAX-versioner.

Som indexerare

På grund av den inneboende beständigheten hos VTD-XML kan utvecklare skriva den interna representationen av ett tolkat XML-dokument till disken och senare ladda om det för att undvika upprepad analys. För detta ändamål har XimpleWare introducerat VTD+XML som ett binärt paketeringsformat som kombinerar VTD, LC och XML-texten. Det kan vanligtvis ses på ett av följande två sätt:

• Ett inbyggt XML-index som helt eliminerar analyskostnaden och även behåller alla fördelar med XML. Det är ett filformat som är läsbart för människor och bakåtkompatibelt med XML.
• Ett binärt XML- format som använder binär data för att förbättra bearbetningen av XML-texten.

XML-innehållsmodifierare

Eftersom VTD-XML håller XML-texten intakt utan avkodning, när en applikation avser att ändra innehållet i XML behöver den bara modifiera de delar som är mest relevanta för ändringarna. Detta står i skarp kontrast till DOM-, SAX- eller StAx-parsning, som medför kostnaden för att analysera och serialisera om oavsett hur små ändringarna är.

Eftersom VTD hänvisar till dokumentelement med sina förskjutningar, kräver ändringar av längden på element som inträffar tidigare i ett dokument justeringar av VTD:er som hänvisar till alla senare element. Dessa justeringar är dock heltalstillägg, om än till många heltal i flera tabeller, så de är snabba.

XML slicer/splitter/assembler

En applikation baserad på VTD-XML kan också använda offset och längder för att adressera tokens eller elementfragment. Detta gör att XML-dokument kan manipuleras som arrayer av byte.

• Som en slicer kan VTD-XML " skiva " av en token eller ett elementfragment från ett XML-dokument och sedan infoga det på en annan plats i samma dokument eller i ett annat dokument.
• Som en splitter kan VTD-XML dela upp underelement i ett XML-dokument och dumpa vart och ett i ett separat XML-dokument.
• Som assembler kan VTD-XML " klippa ut" bitar ur flera XML-dokument och sätta ihop dem till ett nytt XML-dokument.

XML-redigerare/radergummi

Används som redigerare/raderare kan VTD-XML direkt redigera/radera det underliggande byteinnehållet i XML-texten, förutsatt att tokenlängden är bredare än det avsedda nya innehållet. En omedelbar fördel med detta tillvägagångssätt är att applikationen omedelbart kan återanvända den ursprungliga VTD och LC. När VTD-XML däremot används för att stegvis uppdatera ett XML-dokument, måste ett program reparera det uppdaterade dokumentet innan programmet kan bearbeta det.

En redigerare kan göras smart nog att spåra platsen för varje token, vilket tillåter nya, längre tokens att ersätta befintliga, kortare tokens genom att bara adressera den nya tokenen i ett separat minne utanför det som användes för att lagra originaldokumentet. Likaså, när du ändrar ordning på dokumentet, behöver elementtext inte kopieras; bara LC:erna behöver uppdateras. När ett komplett, sammanhängande XML-dokument behövs, till exempel när du sparar det, kan de olika delarna sättas ihop till ett nytt sammanhängande dokument.

Andra fördelar

VTD-XML är också banbrytande för den icke-blockerande, tillståndslösa XPath-utvärderingsmetoden.

Svagheter

VTD-XML uppvisar också några märkbara brister:

• Som en XML-tolkare stöder den inte externa enheter som deklareras i DTD.
• Som filformat ökar det dokumentstorleken med cirka 30 % till 50 %.
• Som ett API är det inte kompatibelt med DOM , SAX eller StAX .
• Det är svårt att stödja vissa valideringstekniker som används av DTD och XML Schema (t.ex. standardattribut och element), som kräver modifieringar av XML-instanserna som tolkas.

Användningsområden

Allmän ersättning för DOM eller SAX

På grund av VTD-XML:s prestanda och minnesfördelar täcker den en större del av XML-användningsfallen än antingen DOM eller SAX.

• Jämfört med DOM, bearbetar VTD-XML större (3x~5x) XML-dokument för samma mängd fysiskt minne med ungefär 3 till 10 gånger prestanda.
• Jämfört med SAX ger VTD-XML slumpmässig åtkomst och XPath-stöd och överträffar SAX med minst 2x.

XPath över enorma XML-dokument

Den utökade utgåvan av VTD-XML i kombination med 64-bitars JVM möjliggör XPath-baserad XML-bearbetning över enorma XML-dokument (upp till 256 GB) i storlek.

För SOA/WS/XML-säkerhet

Kombinationen av VTD-XML:s höga prestanda och inkrementella uppdateringsförmåga gör det viktigt att uppnå önskad servicekvalitet för SOA/WS/XML säkerhetsapplikationer.

För SOA/WS/XML-förmedlare

VTD-XML är väl lämpad för SOA- intermediära applikationer som XML-routrar/switchar/gateways, Enterprise Service Buses och serviceaggregationspunkter. Alla dessa applikationer utför de grundläggande "lagra och vidarebefordra" operationer där det är avgörande att behålla den ursprungliga XML-filen för att minimera latens. VTD-XML:s inkrementella uppdateringsförmåga bidrar också väsentligt till vidarebefordran.

VTD-XML:s slumpmässiga åtkomstmöjlighet lämpar sig väl för XPath -baserad XML-routning/växling/filtrering som är vanligt i AJAX- och SOA-distribution.

Intelligent SOA/WS/XML Lastbalansering och avlastning

När ett XML-dokument färdas genom flera SOA-komponenter på mellannivå kan det första meddelandestoppet, efter att ha avslutat inspektionen av XML-dokumentet, välja att skicka VTD+XML-filformatet till nedströmskomponenterna för att undvika upprepad analys, vilket förbättrar genomströmningen.

På samma sätt kan en intelligent SOA-lastbalanserare välja att generera VTD+XML för inkommande/utgående SOAP-meddelanden för att avlasta XML-tolkning från applikationsservrarna som tar emot dessa meddelanden.

XML-beständighetsdatalager

När det ses ur perspektivet av inbyggd XML-beständighet, kan VTD-XML användas som ett mänskligt läsbart, lättanvänt XML-index för allmänt bruk. XML-dokument som lagras på detta sätt kan laddas in i minnet för att frågas, uppdateras eller redigeras utan att behöva analysera/återserieisera.

Schemalös XML-databindning

VTD-XML:s kombination av hög prestanda, låg minnesanvändning och effektiv XPath-utvärdering möjliggör en ny XML-databindningsmetod baserad helt på XPath. Det här tillvägagångssättets största fördel är att det inte längre kräver XML-schema, undviker onödigt objektskapande och drar fördel av XMLs inneboende lösa kodning.

Det är värt att notera att databindning som diskuteras i artikeln som nämns ovan måste implementeras av applikationen: VTD-XML i sig erbjuder bara accessorer. I detta avseende är VTD-XML inte en databindningslösning i sig (till skillnad från JiBX, JAXB, XMLBeans), även om den erbjuder extraktionsfunktioner för databindningspaket, ungefär som andra XML-tolkare (DOM , SAX , StAX ) .

Viktiga klasser

Från och med version 2.11 består Java- och C#-versionerna av VTD-XML av följande klasser:

• VTDGen (VTD Generator) är klassen som kapslar in huvudfunktionerna för analys, indexladdning och indexskrivning.
• VTDNav (VTD Navigator) är klassen som (1) kapslar in XML, VTD och hierarkisk information, (2) innehåller olika navigeringsmetoder, (3) utför olika jämförelser mellan VTD-poster och strängar, och (4) konverterar VTD-poster till primitiva datatyper.
• AutoPilot är en klass som innehåller funktioner som utför iteration på nodnivå och XPath.
• XMLModifier är en klass som erbjuder inkrementella uppdateringsmöjligheter, såsom radera, infoga och uppdatera.

Den utökade VTD-XML består av följande klasser:

• VTDGenHuge (Extended VTD Generator) kapslar in huvudparsningen.
• XMLBuffer utför laddning i minnet av XML-dokument.
• XMLMemMappedBuffer utför minnesmappad laddning av XML-dokument.
• VTDNavHuge (Extended VTD Navigator) (1) kapslar in XML, Extended VTD och hierarkisk information, (2) innehåller olika navigeringsmetoder, (3) utför olika jämförelser mellan VTD-poster och strängar, och (4) konverterar VTD-poster till primitiva datatyper .
• AutoPilotHuge utför iteration på nodnivå och XPath.

Kodprov

 

   
              
            
                
              
                   
                    
                    
                

                   
                     
                    
                    
                
                
                     
                     
                
                
            
      
 /* I detta java-program visar vi hur man använder XMLModifier för att stegvis *  uppdatera en enkel XML-inköpsorder.  * ett särskilt namnutrymme. Vi kommer också   * att använda VTDGens parseFile för att förenkla programmering.  */  import  com.ximpleware.*  ;  public  class  Update  {  public  static  void  main  (  String  argv  []  )  kastar  NavException  ,  ModifyException  ,  IOException  {  // öppnar en fil och läser innehållet i en byte-array  VTDGen  vg  =  new  VTDGen  ();  if  (  vg  .  parseFile  (  "oldpo.xml"  ,  true  )){  VTDNav  vn  =  vg  .  getNav  ();  AutoPilot  ap  =  ny  AutoPilot  (  vn  );  XMLModifier  xm  =  new  XMLModifier  (  vn  );  ap  .  selectXPath  (  "/köpOrder/artiklar/vara[@partNum='872-AA']")  ;  int  i  =  -1  ;  _  while  ((  i  =  ap  .  evalXPath  ())  !=  -  1  ){  xm  .  ta bort  ();  xm  .  insertBeforeElement  (  "<något/>\n" )  ;  }  ap  .  selectXPath  (  "/köpOrder/artiklar/vara/USPris[.<40]/text()"  );  while  ((  i  =  ap  .  evalXPath  ())  !=  -  1  ){  xm  .  updateToken  (  i  ,  "200"  );  }  xm  .  output  (  "newpo.xml"  );  }  }  }