---

Hej,

Håber I kan hjælpe mig med et lille problem i forbindelse med indlæsning af
XML-data i en database.

Mit problem er at jeg i nogle tilfælde modtager XML-filer, som er "non-well
formed" - der mangler f.eks. et sluttag. DOM-Parseren (Xerces-udgave) nægter
herefter at gå videre. Det eneste jeg nu kan skrive i en logfil er hvilket
XML-fil problemet opstod i og hvad problemet er.
Denne løsning er kunden ikke tilfreds med, da det kræver en del arbejde fra
hans side at finde ud præcis hvad det er for data der skal gensendes fra
tastebureauet. Istedet vil han gerne have at mulighed for at få nogle af
informationerne i XML-filen (f.eks. SE-nummer).

Kan man det ?? Altså tvinge parseren til at "arbejde" videre, selvom
syntaksen ikke er overholdt ?? Jeg kan se at der findes en metode på den
abstrakte klasse XMLParser, som DOMParser'en er en specialisering af, men
denne er protected. Hvorfor ??

Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)

mvh
Martin

---

"Martin Elkjær Nielsen" <martin@mecom.dk> writes:

> Denne løsning er kunden ikke tilfreds med, da det kræver en del arbejde fra
> hans side at finde ud præcis hvad det er for data der skal gensendes fra
> tastebureauet. Istedet vil han gerne have at mulighed for at få nogle af
> informationerne i XML-filen (f.eks. SE-nummer).

Hele pointen med XML er netop at parseren maa bundvende hvis der er noget galt.

Til fremover saa giv kunden en helt almindelig XML-validator (IE kan
gaere det hvis filerne er smaa), og sig at det skal de igennem foerend
du vil se den.

Hvis du har non-conformant XML, saa skal du behandle det som en
SGML-fil. Lav en DTD for formatet, og se om du saa kan parse det med
en SGML-parser. Herefter vil SX fra jclark.com kunne goere det. Det
er C-programmer.

Hvis det haster meget, saa kan I kontakte mig via email.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk

---

Pointen ved XML, er netop at man kun kan stole på dataene så længe
dokumentet er well-formed.

Men hvis ikke det er så vigtigt I jeres tilfælde kan I parse XML
dokumentet vha. SAX og behandle dataene efthånden som de kommer. Når
noget så går galt, er der ikke mere at gøre - så man parseren (og dermed
behandlingen) give op.

-dennis


Martin Elkjær Nielsen wrote:
> Hej,
>
> Håber I kan hjælpe mig med et lille problem i forbindelse med indlæsning af
> XML-data i en database.
>
> Mit problem er at jeg i nogle tilfælde modtager XML-filer, som er "non-well
> formed" - der mangler f.eks. et sluttag. DOM-Parseren (Xerces-udgave) nægter
> herefter at gå videre. Det eneste jeg nu kan skrive i en logfil er hvilket
> XML-fil problemet opstod i og hvad problemet er.
> Denne løsning er kunden ikke tilfreds med, da det kræver en del arbejde fra
> hans side at finde ud præcis hvad det er for data der skal gensendes fra
> tastebureauet. Istedet vil han gerne have at mulighed for at få nogle af
> informationerne i XML-filen (f.eks. SE-nummer).
>
> Kan man det ?? Altså tvinge parseren til at "arbejde" videre, selvom
> syntaksen ikke er overholdt ?? Jeg kan se at der findes en metode på den
> abstrakte klasse XMLParser, som DOMParser'en er en specialisering af, men
> denne er protected. Hvorfor ??
>
> Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)
>
> mvh
> Martin
>
>
>
>

---

Martin Elkjær Nielsen wrote:
<snip/>
> Denne løsning er kunden ikke tilfreds med, da det kræver en del arbejde fra
> hans side at finde ud præcis hvad det er for data der skal gensendes fra
> tastebureauet. Istedet vil han gerne have at mulighed for at få nogle af
> informationerne i XML-filen (f.eks. SE-nummer).

Kunden har vel betalt tastebureauet for at løse en opgave. Hvis deres
XML dokumenter ikke er well-formed, så er opgaven ikke løst. XML i
dataudveksling er ofte betragtet som en kontrakt mellem 2 parter, et
veldefineret format, hvor ganske få regler er overholdt. I dit
tilfælde overholder leverandøren ikke sin del af "kontrakten".

<snip/>

> Kan man det ?? Altså tvinge parseren til at "arbejde" videre, selvom
> syntaksen ikke er overholdt ?? Jeg kan se at der findes en metode på den
> abstrakte klasse XMLParser, som DOMParser'en er en specialisering af, men
> denne er protected. Hvorfor ??

Af ren nysgerrighed, hvilke pakker er XMLParser og DOMParser i? En model
du evt. kan bruge er, at implementere SAX. Jeg vil antage at du bare som
altid vil få smidt events i hovedet indtil der er noget galt. Det er ret
nemt at implementere.

> Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)

Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
hvis det tager JVM'en bare 1 sekund at initialisere for hvert
dokument, har du et overhead på over 10 timer. Hvis du har alle
dokumenterne som well-formed XML, er det ligetil at konkatenere dem
og wrappe den fremkomne fil med nyt root tag, prolog osv.

Mvh Morten

---

Morten wrote:
> Martin Elkjær Nielsen wrote:
>> Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)
>
>
> Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
> hvis det tager JVM'en bare 1 sekund at initialisere for hvert
> dokument, har du et overhead på over 10 timer. Hvis du har alle
> dokumenterne som well-formed XML, er det ligetil at konkatenere dem
> og wrappe den fremkomne fil med nyt root tag, prolog osv.

Ja, eller evt. lave applikation så den kan håndtere flere filer end én
pr. gang den køres.

-dennis

---

Dennis Thrysøe wrote:
> Morten wrote:
>
>> Martin Elkjær Nielsen wrote:
>>
>>> Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)
>>
>>
>>
>> Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
>> hvis det tager JVM'en bare 1 sekund at initialisere for hvert
>> dokument, har du et overhead på over 10 timer. Hvis du har alle
>> dokumenterne som well-formed XML, er det ligetil at konkatenere dem
>> og wrappe den fremkomne fil med nyt root tag, prolog osv.
>
>
> Ja, eller evt. lave applikation så den kan håndtere flere filer end én
> pr. gang den køres.
>

Naturligvis. Jeg prøvede blot at konstatere endnu en fordel ved
at have well-formed XML når værktøjerne benyttes command line
(som ofte er tilfældet med Xalan/Xerces når du ikke arbejder på
en decideret applikation).

---

"Dennis Thrysøe" <dt@netnord.dk> skrev i en meddelelse
news:3C6BA430.3010500@netnord.dk...
> Morten wrote:
> > Martin Elkjær Nielsen wrote:
> >> Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)
> >
> >
> > Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
> > hvis det tager JVM'en bare 1 sekund at initialisere for hvert
> > dokument, har du et overhead på over 10 timer. Hvis du har alle
> > dokumenterne som well-formed XML, er det ligetil at konkatenere dem
> > og wrappe den fremkomne fil med nyt root tag, prolog osv.
>
> Ja, eller evt. lave applikation så den kan håndtere flere filer end én
> pr. gang den køres.

Det er faktisk præcis sådan det virker.
Morten's pointe er vel at der kun skal indlæse en (stor) fil, istedet for
mange små, som koster tid, da filsystemet skal tilgås noget oftere ??

Martin

---

Ja, men det vil være ret begrænset hvad gavn man ville have af, at
skrive mange XML dokumenter sammen i en stor fil.

Med mindre selvfølgelig filen skal bearbejdes et stort antal gange.

Hvis det kun drejer sig om få gange kan det vel bedre betale sig at
parse en masse små filer, end at parse en masse små filer, sætte dem
sammen i hukommelsen, skrive en stor fil til disk og tilsidst parse denne.

Men idéen er god nok i nogle sammenhænge.

-dennis



Martin Elkjær Nielsen wrote:
> "Dennis Thrysøe" <dt@netnord.dk> skrev i en meddelelse
> news:3C6BA430.3010500@netnord.dk...
>
>>Morten wrote:
>>
>>>Martin Elkjær Nielsen wrote:
>>>
>>>>Håber nogle kan hjælpe (der ligger ca. 55.000 dokumenter og venter!)
>>>>
>>>
>>>Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
>>>hvis det tager JVM'en bare 1 sekund at initialisere for hvert
>>>dokument, har du et overhead på over 10 timer. Hvis du har alle
>>>dokumenterne som well-formed XML, er det ligetil at konkatenere dem
>>>og wrappe den fremkomne fil med nyt root tag, prolog osv.
>>>
>>Ja, eller evt. lave applikation så den kan håndtere flere filer end én
>>pr. gang den køres.
>>
>
> Det er faktisk præcis sådan det virker.
> Morten's pointe er vel at der kun skal indlæse en (stor) fil, istedet for
> mange små, som koster tid, da filsystemet skal tilgås noget oftere ??
>
> Martin
>
>
>
>

---

"Morten" <morten@kikobu.com> skrev i en meddelelse
news:3C6B9FE1.6080304@kikobu.com...
> Martin Elkjær Nielsen wrote:
>
> Kunden har vel betalt tastebureauet for at løse en opgave. Hvis deres
> XML dokumenter ikke er well-formed, så er opgaven ikke løst. XML i
> dataudveksling er ofte betragtet som en kontrakt mellem 2 parter, et
> veldefineret format, hvor ganske få regler er overholdt. I dit
> tilfælde overholder leverandøren ikke sin del af "kontrakten".
>

Helt enig, og i fremtiden har de også lovet at anvende den DTD de har fået
udleveret fra starten. Problemet består i at få indlæst de 16.000 skemaer
der er indtastet (uden brug af DTD'en som de havde lovet), på den mest
smidige måde. Hvem der så betaler for de timer jeg skal bruge, det lader jeg
min chef om at diskutere

> Af ren nysgerrighed, hvilke pakker er XMLParser og DOMParser i? En model
> du evt. kan bruge er, at implementere SAX. Jeg vil antage at du bare som
> altid vil få smidt events i hovedet indtil der er noget galt. Det er ret
> nemt at implementere.

org.apache.xerces.parsers
Jeg vil prøve at kigge lidt på SAX parser som også findes i denne pakke. Det
ser ud til at den kan løse lidt af problemet.

>
> Et lille tip. Jeg har for nyligt arbejdet på >40.000 XML dokumenter,
> hvis det tager JVM'en bare 1 sekund at initialisere for hvert
> dokument, har du et overhead på over 10 timer. Hvis du har alle
> dokumenterne som well-formed XML, er det ligetil at konkatenere dem
> og wrappe den fremkomne fil med nyt root tag, prolog osv.

Imponerende så mange tips, man kan få ved at stille et spørgsmål
Men jeg tror jeg holder mig til den nuværende løsning, da der kun kommer ca.
600 dokumenter om dagen, og EDI postkassen tømmes ca. hver time. En
indlæsning tager ca. 1 sek for hele processen (fra åbning af fil til DB er
opdateret).

mvh
Martin