XML, hvad er alternativet?

Jeg har aldrig været særlig glad for XML. Det vil sige, XML som grundlag for en striks udgave af HTML (altså xhtml) er jeg meget glad for. Men XML som reflekssvar på problemstillingen "vi skal bruge et dataformat" har generet mig lige siden begyndelsen.

Specielt de to store løgne om XML generer mig: "Hvis vi bruger XML er vi åbne/kompatible med alt/standardiseret" og "Hvis vi bruger XML er kan filerne redigeres i hånden". Det første er klart forkert når man indser at XML bare er ren struktur, XML fortæller os ikke hvad data betyder. Den anden løgn er mindre indlysnede og måske langt mere subjektiv. Velopsatte simple XML-strukturer kan måske redigeres i hånden, men simple ting er lettere håndteret i simplere formater. Komplekse strukturer er nærmest et kapløb og det er XML eller strukturen der spænder mest ben for at redigere data i hånden.

Ideen med ikke at skulle definere et dataformat fra bunden af, og skrive nye parsere hver gang man skal definere et format for en ny type data er god. Det er en God Ting(tm) bare at kunne gribe ned i værktøjskassen efter et standardværktøj der tager sig af hele strukturen, så man kun skal bekymre sig om fortolkningen af data (desvære ser jeg stadig folk der forsøger at parse XML med et par hjemmebrygget regulære udtryk). Men hvorfor nøjes med et format, der i bedste fald ikke er godt til alt og i værste fald er dårligt til det meste? Her er et udvalg af mine standardformater:

Simple filer

Jeg har set folk bruge XML der reelt set bare beskrev en flad liste af simple værdier. Så hvor trivielt det end lyder er det første standardformat én værdi per linje. Værdier er for eksempel domæner, email-adresser, tal eller hvad som helst. Så simpelt at det kan parses med en linje bourne shell.

INI-filer

INI-filer er vist godt nok en Microsoft-opfindelse, men til ganske meget konfiguration er selv simple INI-parsere tilstrækkelige. Er INI-filer for primitive til din konfiguration, så brug lige 5 minutter på at overveje om din konfiguration ikke er overdesignet. To gode grunde til at man ikke bruger INI-filer: Man koder i bourne shell og kan nøjes med noget der ligner environment-variable eller at ens projekt i forvejen er søbet ind i et lige så redigerbart dataformat. Perlfolk kan bruge Config::Tiny, Config::INI::Reader eller et dusin andre moduler.

YAML

Normalt ville jeg medtage noget ala RFC822 mail-headers, men på det seneste er jeg blevet interesseret i at bruge YAML, men YAML kan beskrive vilkårlige træstrukture bestående af både simple lister og key/value-par. Egentlig ikke meget mindre kompliceret end XML, men lidt frækt vil jeg måske sammenligne XML med Lisp og YAML med Pascal eller C. Perlfolk kan se på YAML::Tiny, YAML eller YAML::Syck.

CSV-filer

Og endelig en gammel traver: Comma-Separated Values. Naivt set er det simpelt at læse en linje og splitte den op på kommaer. Men hvis man ikke har kontrol over hvad der står i ens CSV-filer, bør man nok bruge noget mindre naivt, der understøtter felter der indeholder kommaer eller linjeskift. Perlfolk bør se på Text::CSV::XS, alle andre bør læse RFC4180.

Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#5 Palle Simonsen

Hvis man er gammel LISP hacker vil man vide, at i LISP gemmer man ofte data som LISP. Dermed sparer man bl.a. anstrengelsen med at skrive en parser. Hvis man er bekymret for load tid slutter man bare af med (compile "my-data-file.lisp") :)

  • 0
  • 0
#6 Troels Arvin

Det er uklart om du udelukkende fokuserer på formater til konfigurationsfiler. Hvis man må zoom'e lidt ud og kigge på formater med messaging-fokus:

Hvad med ASN.1 og én af dens encoding rules? Det er da en standard som både er åben og gennemprøvet i virkeligheden.

(Jeg beklager den usystematiske blanding af engelsk og dansk.)

  • 0
  • 0
#7 Jacob Christian Munch-Andersen

Rart at se at man ikke er den eneste i verden der har svært ved at se hvorfor XML er så pokkers smart. Man kan bytte om på elementernes rækkefølge som man lyster, med det resultat at der skal bruges store mængder plads på at navngive de enkelte elementer. I bedste fald skal parseren læse hele filen igennem og opbygge en indeksering før man kan begynde at trække data ud, og i værste fald tæsker den hele filen igennem hver gang man forespørger et enkelt stykke data.

Jeg tror at mange ikke er klar over hvor let det egentlig er at hjemmebrygge et format.

Til gengæld ser det da ud til at nogle folk har rigeligt svært ved at lave gode filformater med XML. Jeg lavede lige en test fil i Calc, den fylder 5928 byte før jeg overhovedet har indtastet noget som helst, det er alligevel meget hvis man prøver at gætte på hvad det egentlig kan være der død og pine tilsyneladende skal stå i alle mine regneark, hvad så med de rigtige data, hvor godt er de komprimeret? Jeg fyldte da lige en streng på 11 tegn ind i A1 for at se hvorledes det skalerer. Resultatet var 6478 byte, altså 550 byte mere end en "tom" fil, er det bare den første streng som lige kræver at der fyldes lidt mere guf i headeren? Nej, 7 tegn i C6 lagde yderligere 257 byte til filen. (Og nej, jeg tror ikke at XL filer er et hak bedre.)

Det er jo ikke fordi at min harddisk dør af at et regneark fylder over 10 gange så meget som det burde, men snarere end i sig selv at være et problem er det nok et symptom på nogle problemer, som nok også rækker ud over XML. XML er det åbenlyse flagskib for redundans og spild, men problemerne er nok i virkeligheden langt større i de lag hvor de ikke er så åbenlyse. Offices her på siden omtalte fedmeproblemer er ikke et resultat af et enkelt fejlslagent format, det er resultatet af en kultur som er ligeglad med hvor groft systemresourcerne udnyttes, bare det kan køre nogenlunde på en moderne computer så er det sq ligegyldingt om der er fyldt 100 gange så meget lort i rammen som nødvendigt.

  • 0
  • 0
#8 Jens Jakob Andersen

Kære Peter

Dit indlæg har jo en interessant vinkel, "Silverbullets, hvad er alternativet".

Det er vel der vi har kernen i udfordringen, det er jo ikke XML's skyld at det bliver af mange set som en silverbullet til at løse alting :-)

Overskriften kunne ligesåvel have været "WML, hvad er alternativet", "OO, hvad er alternativet" osv - etc. etc.

XML i sig selv er jo bare en standard for at beskrive hierakiske strukturer - med et hav af tilhørende værktøjer. Set ud fra udbredelsen af teknologi omkring er det IMHO et godt bud på en success.

Men når bliver en success, eller lugter af success, dukker der også hype op ( kan bruges til alt og er selvbeskrivende), og mange anvendelser, hvoraf nogle sub-optimale.

Måske det rette korstog ville være en genindførsel af læsning af Knuths bøger som basis-pensum, inden nogen får lov til begynde at kode? http://en.wikipedia.org/wiki/Donald_Knuth

Gode hilsner

Jens Jakob

  • 0
  • 0
#9 Peter Makholm Blogger

Angående DSL'er, så er der selvfølgelig tidspunkter hvor det er på sin plads. Men som Bjarne Stroustrup udtaler andetssted[0], så helst som sidste udvej og ikke som første forslag. I Varnish er det på sin plads, for her har vi brug for "et programmerinssprogs muligheder". Men ulempen er at man kun har meget lidt kode at genbruge og at brugeren skal lære et nyt sprog.

0) http://www.version2.dk/artikel/6972

Nu har jeg godt nok leget mest med Scheme, men det er rigtig nok at det kan have sine rare sider at bare anvende lisp-udtryk som data. Men jeg mener ikke at det er et specielt brugervenligt dataformat for andre end folk der er vandt til lisp-syntaks. Og det er ikke en specielt bred brugergruppe.

I Emacs er lisp-syntaks både brugt som konfigurationsformat og til tider generelt data-bærende format. Det kan godt være at det sidste er praktisk ud fra et udvikler synspunkt, men det er ikke specielt rart at skulle rette Gnus' .newsrc.eld i hånden.

Der hvor jeg har været glad for Scheme er når grænsen mellem data og kode er tværet ud, som når man laver programmer der bearbejder programkode. Så er det rigtig rart ikke at skulle lege med en C-ligende syntaks.

Jeg mener ikke at jeg fokusere specielt meget på konfiguration. Jeg vil absolut fraråde at man anvender CSV som konfigurationsformat og en flad liste opfatter jeg sjældent som konfiguration. Jeg må tilstå at jeg aldrig har set nærmere på ASN.1, så derfor ved jeg reelt ikke noget om det. Men det giver selvfølgelig en interessant fleksibilitet at adskille definitionen af vores struktur fra den konkrete encoding.

  • 0
  • 0
#12 Peter Makholm Blogger

Du har ret i at man kunne skrive tilsvarende indlæg for mange andre af branchens såkaldte silverbullets. Men for det konkrete indlæg kunne overskriften ikke ligesåvel have været "OO, hvad er alternativet". Mit indlæg handler nemlig om et konkret problemområde, hvor folks foretrukne silverbullet hedder XML.

Det er sikkert ikke sidste gang jeg har lyst til at tage en konkret silverbullet op og foreslå alternativer og det er sikkert heller ikke utænkeligt at jeg på et tidspunkt kunne tænke mig at skrive om silverbullet-begrebet i sig selv. Men det gør absolut ikke de konkrete indlæg overflødige.

  • 0
  • 0
#13 Erik Cederstrand

@Thomas

Det er netop min største anke ved XML. Har lige stødt på et tilsvarende eksempel, hvor data blev ca 50 gange større af at blive konverteret til et OIO-velsignet XML Schema (tags à la "").

Det ville være til at bære, hvis komprimering så bare var indbygget i kommunikationsprotokollerne, f.eks. SOAP. 200MB tager lidt tid at få gennem en ADSL-linie.

  • 0
  • 0
#14 Mikkel Meyer Andersen

Det er korrekt, at XML fylder meget - og ofte mere end nødvendigt - men jeg har enormt stor glæde af, at man i mange systemer har valgt at benytte XML til dataudveksling. Det gør trods alt interfaces mellem systemer nemmere at lave, når der benyttes samme format end hele tiden at skulle røre ved forskellige - og så kommer sprog som XSLT også virkelig til sin ret.

Så jeg er enig i kapacitetsproblemerne, men jeg er enormt glad for at man i så stor udstrækning er blevet "enige" om et fælles format.

Så når alt kommer til alt, er det vel igen et spørgsmål om at anvende det rigtige værktøj til den rigtige opgave. Hvis man laver systemer med en eller anden dataudvekslingsmekanisme, så synes jeg XML er det rigtige valg, men til eksempelvis konfigurationsfiler skal man naturligvis finde ud af, hvad der vil være smartest til opgaven.

  • 0
  • 0
#16 Kristian Poulsen

@Erik Cederstrand

Jeg ved ikke om det er et problem at OIO navne er lange og kommer til at hedde noget i stil med ""

Det skal trods alt være sigende og unikt.

Sådan som jeg ser det er problemet at hvis det skal være rigtig OIO'sk, så kommer det jo til at hedde noget i stil med

""

til hvilken nytte ?

Jo så kan man validere dokumentet via de officielle schemaer, men det kan jeg i hvert fald ikke få til at fungere ordentligt. Schemaerne refererer jo til hinanden og jeg har kun fået det til at virke ved manuelt at samle alle schemaer til et stort.

Og ærlig talt - det er ikke besværet værd, så der er ikke de korrekte namespaces i mine xml-dokumenter/web services...

Jeg kan ikke huske hvornår jeg sidst har parset et XML dokument. Nu arbejder jeg med .Net og der udnytter jeg muligheden for at deserialisere XML til typestærke objekter, for at arbejde videre på dem.

DET VIRKER BARE !

  • 0
  • 0
#17 Erik Cederstrand

Min pointe var, at hvis man ikke tænker sig om, kan man nemt tvinge et stykke software i knæ, hvis alting skal være SOA og data udveksles med XML.

Eksemplet med OIO illustrerer, at de sendes utrolig meget overflødig data over linien. At 2KB bliver til 100KB er måske ligemeget, men når 2MB bliver til 100MB betyder det alt for lange svartider. XML skalerer ikke, med mindre komprimering er involveret.

  • 0
  • 0
#18 Peter Makholm Blogger

Det er selvfølgelig meget sødt med en standard der gør en del ud af at den kan autodetektere mellem UCS-4 og UTF-16 i diverse byte-rækkefølger samt ASCII eller EBDIC - men ærlig talt, det er et trivielt trick at forsøge sig med forskellige transformationer indtil man opnår den forventede magiske værdi.

  • 0
  • 0
#21 Gustav Brock

men ærlig talt, det er et trivielt trick at forsøge sig med forskellige transformationer indtil man opnår den forventede magiske værdi.

Det er lige præcis det, det ikke er. Skal der forsøges, er det en manuel proces. Sådan en tager tid og kan fejle og vil dermed fejle før eller siden. Man skal nok finde ud af det, bevares, men det er ulige nemmere og sikrere, at både programmør og program entydigt kan se, hvordan filen skal læses. Det er én kontrolfunktion, der derved spares, og taler vi kvalitetssikring og effektivitet, er det guld.

/gustav

  • 0
  • 0
#23 Christian Schmidt Blogger

Enig, hver ting til sin tid.

(i det følgende tænker jeg mest på filformaterne som middel for dataudveksling mellem forskellige parter)

Til ikkehierarkiske lister af simple data, der ikke kan indeholde specialtegn (linjeskift mv.), er en tekstfil med én værdi pr. linje nem at have med at gøre. Bl.a. kan man supernemt lave simple operationer som sortering, filtrering mv. på selv rigtig store filer vha. standardværktøjer som grep, cut, sort osv.

CSV-filer kan være fristende, men de har den ulempe, at CSV er et rimelig vidt begreb, og en CSV-fil kan derfor ikke kan læses uden en medfølgende forklaring af, hvad der er skilletegn, escapetegn osv. Jovist er én variant beskrevet i en RFC, men der er også mange andre varianter i omløb.

Til visse formål er Excelfiler (de "gammeldags" .xls-filer) velegnede. Filformatet er proprietært men dog relativt velbeskrevet og understøttet i mange forskellige programmer og biblioteker. De fleste har et regnearksprogram installeret på deres pc, hvor de let kan manipulere med en Excelfil. En stor ulempe er begrænsningen på 65.000 rækker (grænsen er noget højere i OOXML-udgaven af Excelfiler, men understøttelse for dette format er indtil videre ret begrænset).

Et hjertesuk: Man skulle tro, at XML var så udbredt, at de fleste moderat begavede it-folk kunne producere en fejlfri XML-fil, men det synes desværre ikke at være tilfældet. Jeg ved ikke, om disse folk ville have mere held med at producere nogle af de andre filformater, der er nævnt her.

@Jacob Christian: "I bedste fald skal parseren læse hele filen igennem og opbygge en indeksering før man kan begynde at trække data ud [...]" Det er ikke nødvendigt med en SAX- eller pullparser.

Jeg kan ikke se noget til hinder for at bygge en XML-parser, der tilbyder XPath-forespørgsler eller eksponerer et sædvanligt DOM-kompatibelt API uden at indlæse hele filen først, men jeg kender ikke til implementationer heraf.

@Erik: "Det ville være til at bære, hvis komprimering så bare var indbygget i kommunikationsprotokollerne, f.eks. SOAP." I det omfang SOAP benytter HTTP som transportprotokol, kan man vel benytte Content-Encoding: gzip.

@Peter: "Det trick XML-specifikationens appendix E beskriver er ret trivielt. (Appendix F i XML 1.0)." Så vidt jeg har forstået, kan dette trick ikke anvendes til at skelne mellem UTF-8 og ISO-8859-1, hvilket er de to tegnsæt, jeg hyppigst oplever blive forvekslet.

  • 0
  • 0
#24 Rune Juhl-Petersen

Til XML findes der f.eks. XML schema til at definere hvordan xml må se ud. Det er f.eks. muligt at definere hvordan en email skal se ud og om den er påkrævet i filen. Det er muligt definere rækkefølgen på felterne og en helt masse andet.

"XML er ikke velegnet til at brugeren kan taste data i det". Well, da man som sagt både få hjælp til at udfylde sin xml og til at validere at det nu også opfylder de krav der er.

Jeg kan ikke forstå dem der synes det er meget kompliceret at læse xml dokumenter programmatisk. Prøv at søg om der ikke er nogen der har lavet noget smart til jeres specifikke programmeringssprog. Det tager mig en linie kode at loade min xml op i mit XmlDom objekt. Det tager mig en linie kode at finde lige præcist den node jeg er interesseret i (XPath er nøglen). Ligeledes kan jeg læse en liste af noder igennem der opfylder mine krav. Det er meget nemmere end at læse ini filer eller at læse csv. Det er klart at der er implementationer der er bedre end andre, jeg er f.eks. ikke vild med sax parseren da det er lidt omvendt af hvad jeg er vandt til. Man behøver jo ikke nødvendigvis starte med at opfinde hjulet hver gang eller hvad?

INI filer kan da være meget gode, men for brugeren er det jo en gang gætværk, eller prøve sig frem efter eksemplerne. CSV har også problemer. Har lige lavet en løsning til en kunde der spyttede en masse date ud i csv filer. Det går godt lige indtil en med dansk excel læser filerne (; i stedet ,). Så havde jeg hellere leveret noget xml.

Angående navngivning på noder i xml synes jeg klart at de skal være så lange at de klart kan forstås. De fleste komprimerings algoritmer komprimerer ved at finde gentagelser, og xml der derfor som skabt til at blive komprimeret. Om navnene på noder er korte eller lange kommer ikke til at gøre den store forskel når det er komprimeret.

Jeg synes XML er nemmere end ini og csv at gå til, og synes da det burde være et naturligt valg hvis man har muligheden for at vælge. Der er dog én ting jeg gerne går uden om i XML, og det er namespaces. Namespaces gør en masse nemme ting svære :) Det er smag og behag: Vi har jo også stadig damptogsentusiaster ;)

  • 0
  • 0
#26 Flemming Sørensen

For nogle mennesker er XML svaret på livets store spørgsmål, men for mig er svaret Syllable's os::Settings, som er yderst velegnet til meget andet end Settings. Den lagre værdier som Key/Value/Index og filerne kan redigeres (bare ikke i en tekst editor), hvis der skulle blive brug for det.

Nemt at bruge, altid lige ved hånden, og så kan det klares med meget få linjer kode. http://development.syllable.org/documentation/API/LibSyllable/classos_1_...

Eneste problem er faktisk at det er et Syllable only format, men det er til at leve med...

  • 0
  • 0
#27 Peter Makholm Blogger

Det tager ligeledes mig en linje kode at læse end YAML-file eller en INi-fil ind, og atter en linje kode at finde den nøgle jeg har brug for. Jeg vinder ikke noget ved at bruge XML. Og dette uden at skulle opfinde nogle hjul - koden findes og jeg henviser til den i mit blogindlæg.

Der skal ikke mindre gætværk til at skrive en ini-fil end der skal til at skrive en XML-fil. I begge tilfælde slår man op i dokumentationen og ser hvilke nøgler/tags der er forventet. Skal jeg validere en INI-fil læser jeg den ind og tjekker at der er de nøgler jeg forventer. Skal jeg validere en XML-fil lærer jeg mig et domænespecifikt sprog og sender det, samt XML-filen efter et elelr andet program.

Navngivning i både generelt og når man definere et XML-baseret format er svært. Det er meget kulturelt bestemt hvad der er et godt navn. Navne skal selvfølgelig være sigende. Det bliver i hvert fald helt umuligt at redigere XML-filer hvor navngivningen er af standarden w:rPg eller o:rFnt. Men man kan nu også gå et skridt for langt og kalde elementer CentralePersonRegisterIdentifikationsNummer - det er der ikke nogle der kalder CPR-nummeret i virkeligheden.

  • 0
  • 0
#28 Gustav Brock

Hvis man er dybt forelsket i ini-filer eller fx Excel-filer (som i øvrigt for hvem, der gider, nu er fuldt specificerede: http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx) eller for den sags skyld vil skrive sin helt egen byte stream til en fil, er det helt frit at gøre så.

Det er bare trist, hvis man af den grund ikke kan se perspektivet i en standard, der stort set er anerkendt overalt, kan håndtere alle tegnsæt, kan bruges til stort set alt, og understøttes af et utal af værktøjer og systemer. At den så nogle gange fylder noget mere end "nødvendigt", kan betragtes som prisen for dette under.

Som med alt andet, hvor man skal tilpasse sig en standard, må man give og tage lidt, men det er prisen værd. Og selv om det kan se pjattet ud at skrive 10 parametre som en XML-fil, så er det jo i praksis fuldstændigt ligegyldigt, om det er det ene format eller andet. Så man kan lige så godt vælge XML, hvis det man udvikler skal vedligeholdes af andre; de næste øjne, der ser, vil umiddelbart være klar over, hvad der foregår.

Egentlig er det imponerende, at en sådan standard er blevet fremavlet. Nu skal den bare bruges over alt, og det er fint, at det offentlige herhjemme går foran. De, der fx har siddet og bokset med fx bankernes filformater til udveksling af kontooplysninger og betalinger - der er fem helt inkompatible formater - eller lignende, vil i hvert fald værdsætte det.

Peter må beholde sine kæle-csv-filer for mig - jeg har endda et par stykker, let brugte, han kan få!

/gustav

  • 0
  • 0
#29 Peter Makholm Blogger

Det er nok bare mig, men jeg mangler nogle mellemregninger fra at jeg kommer med en håndfuld alternativer til XML i forskellige situationer til at jeg er "dybt forelsket i ini-filer". Jeg har ingen kæle-filer, men dit ordvalg antyder at enhver seriøs debat med dig er udelukket?

  • 0
  • 0
#30 Thomas Ammitzbøll-Bach

Du er jo dybt forelsket...

"Det var pludselig som om, at musikken i rummet forsvandt. Som om alle andre i rummet forsvandt. Ja, som om rummet selv forsvandt. Den velkonfigureret ini-fil lå der i Peters hjemmekatalog med alle sine sektioner og nøglerord på en måde, så han ikke længere kunne holde sig tilbage. Forsigtigt parsede han filen ind i sit perlscript uden modstand fra dens yndefulde bits. Var det som om at Universet havde planlagt denne rendezvous uden de begge kunne forhindre det. At det efterlod Peter helt paf, var der ikke noget mærkeligt i. Hans tanker var aldrig gået i retning af ini-filer og slet ikke denne. Men med et var alt nu forandret. Skulle han vælge den sikre fremtid eller skulle denne stormfulde hændelse tillades at slå hans skæbnes skib ud af kurs?"

Ak ja, Peter, det måtte jo ske...

Thomas

  • 0
  • 0
#31 Gustav Brock

Hø hø, så vidt strakte min fantasi ikke, men velkommen i klubben af useriøse, der har vendt blikket fremad.

Altså, jeg har også en gang lavet funktioner til at læse og skrive Windows Tetris' resultatfil, så jeg kunne lave mine egne high-scores og finde ud af, hvorfor de ikke kunne blive større en 32 tusinde og noget. Det blev ikke til mere - jeg har aldrig brugt rutinerne til andet end sjov.

Som sagt mener jeg, at man må gøre, som man vil - csv, ini, whatever - og da især til en eller anden hyggeapplikation, andre ikke skal vedligeholde. Så hvorfor ikke gemme op til 20 parametre i en Tetris hst-fil på 660 bytes? Der er rigtig mange muligheder.

/gustav

  • 0
  • 0
#32 Kristian Dalgård

Generelt er der ikke noget, man kan gøre for at hjælpe folk, der selv skaber deres problemer. Jeg er ikke et øjeblik i tvivl om, at XML vil erobre verden på de punkter, hvor det er praktisk. Og det er nogle vigtige punkter.

Fordelene ved standarder, data validation og extensibility er så indlysende og den grundlæggende måde at opfatte data på som "nestede", "extensible" strukturer så /rigtig/ at det næsten ville være synd at kalde det genialt. Native xml-databaser går en storslået fremtid i møde og relationelle databaser kommer hurtigt til at virke oldnordiske på mange specifikke områder.

Det eneste skår i glæden er, som mange så harmdirrende påpeger, at XML indebærer en i mange situationer unødigt stor overhead. Men en kommende standard for en binær version af XML vil hjælpe meget på det.

  • 0
  • 0
#33 Bryan Rasmussen

Det er muligt at bruge XML Schema uden en targetNamespace: http://www.w3.org/TR/xmlschema-0/#UndeclaredTNS

"So, to validate a traditional XML 1.0 document which does not use namespaces at all, you must provide a schema with no target namespace. Of course, there are many XML 1.0 documents that do not use namespaces, so there will be many schema documents written without target namespaces; you must be sure to give to your processor a schema document that corresponds to the vocabulary you wish to validate."

  • 0
  • 0
Log ind eller Opret konto for at kommentere