Nekromanti Format

[Troberg]

En fråga som är aningen OT, men tillräckligt nära för att jag ska komma undan med det.

Jag funderar på att göra ett program för att skriva regler som ska vara fritt tillgängliga. Min tanke är att man strukturerar upp reglerna i något slags hierarkisk struktur, liknande följande:

<pre>
Titel
Kapitel 1
Rubrik 11
Underrubrik 111
Underrubrik 112
Underrubrik 113
Rubrik 12
Underrubrik 121
Underrubrik 122
Kapitel 2
Rubrik 21
Underrubrik 211
Underrubrik 212
</pre>



osv. Naturligtvis ska det vara mer beskrivande namn, jag orkade bara inte hitta på vettiga exempel.

OK, man dunkar alltså in sin text i en strukturerad form. What's new?

Jo, någon annan (låt oss kalla honom Adam) kanske inte gillar regeln som finns i Underrubrik 112. I traditionella system kopierar han rubbet, ändrar Underrubrik 112 och är nöjd. Bertil kanske inte gillar regeln i Underrubrik 113 och gör motsvarande ändring. Problemet kommer när Ceasar vill använda både Adams och Bertils ändringar, så han manuellt måste gå genom och sammanställa sin version.

I mitt tänk så skulle Adam och Bertil i stället bara göra sin egen Underrubrik 112 resp Underrubrik 113, eftersom de inte ändrar annat. De skulle sedan spara sina ändringar som en mod, vilken Ceasar sedan kan ta hem och applicera automatiskt i programmet. Ceasar kan då stapla olika moddar och har dessutom översikt över vad som verkligen ändras. Moddar ska naturligtvis också kunna innebära att bitar tas bort, läggs till eller flyttas. En mod ska även naturligtvis kunna ändra flera avsnitt.

Man kan till och med få ut mätetal över hur mycket en mod ändrar i olika delar av systemet, vilket man kan använda som en indikation på om man tycker den verkar intressant eller inte.

Japp, det är ju trevligt. Men layout då?

Jo, här kommer min fråga. Man vill ju ha kontroll över layouten, men det hör ju inte hemma i detta program. Lösningen är ju då mallbaserad export till något standardformat som man sedan kan arbeta vidare med i ett lämpligare verktyg. Man häller så att säga ner data i sin egen form (och kan därmed också få sin egen layout även på sådant andra gjort).

Problemet? Vilket format ska man använda?

Som jag ser det så finns det egentligen bara tre alternativ som är någotsånär standardiserade: LaTeX, HTML och ren text. Andra alternativ har alla nackdelar: Postscript och PDF lämpar sig inte för vidare redigering, Word är inte standardiserat på långa vägar när och är dessutom inte dokumenterat så att man kan göra egna dokument, XML klarar bara ett subset av text, övriga är för smala.

Även de tre tänkbara alternativen har problem:

LaTeX är ganska struligt under Windows.
HTML är dåligt standardiserat (mindre problem, man kan hålla sig till ett enkelt subset), dåligt lämpat för utskrift.
Text har ingen formatering, så man måste själv gå genom och justera vad som är rubriker et cetera.

Några förslag? Har jag missat något skoj format?

Kan det till och med vara så att jag sitter och skriver på något som redan finns?

 

[wilper]

Skriv en fin manul så att windowsmänniskorna vågar lära sig LaTeX.

 

[Krille]

"Några förslag? Har jag missat något skoj format?"

Jupp. RTF. Det är dokumenterat, öppet, allmängiltigt och dessutom rätt enkelt att koda.

 

[Kimon]

Några förslag? Har jag missat något skoj format?

Har du kollat på Docbook?

 

[Dimfrost]

Det här känns vagt bekant, rentav formuleringarna på sina ställen. Är det möjligtvis så att du har tröttnat på att alltid hänvisa till "det där geniala inlägget ingen svarade på"?

Om man exporterar till ren text borde man kunna lägga upp texten så att man kan klippa in det i Word och autoformatera det på lämpligt sätt. Nu vet jag inte riktigt vad som ska till för att Word ska tro att en viss textsnutt är rubrik, men det är ganska trevligt att ha en grundformatering innan man slänger in texten i Pagemaker eller InDesign för den riktiga layouten

Men det är en bra idé. Det kan säkert komma något intressant av det här.


/Dimfrost

 

[Troberg]

Det här känns vagt bekant, rentav formuleringarna på sina ställen. Är det möjligtvis så att du har tröttnat på att alltid hänvisa till "det där geniala inlägget ingen svarade på"?

Japp.

Om man exporterar till ren text borde man kunna lägga upp texten så att man kan klippa in det i Word och autoformatera det på lämpligt sätt. Nu vet jag inte riktigt vad som ska till för att Word ska tro att en viss textsnutt är rubrik, men det är ganska trevligt att ha en grundformatering innan man slänger in texten i Pagemaker eller InDesign för den riktiga layouten

En tanke är att exportera i ren text, med markörer som markerar rubrik och sånt. Dessa markörer borde man ganska lätt kunna göra makros för att byta ut mot verklig formatering i de flesta verktyg.

 

[Troberg]

Jupp. RTF. Det är dokumenterat, öppet, allmängiltigt och dessutom rätt enkelt att koda.

Iofs, det är ett tänkbart alternativ. Jag vet inte hur formatet ser ut, frågan är hur lätt det är att göra mallbaserat så att man lätt kan göra egna mallar?

 

[Troberg]

Har du kollat på Docbook?

Japp, men jag fick snabbt allergiska utslag av det eviga tjatet om XML.

 

[Krille]

RTF

"Jag vet inte hur formatet ser ut, frågan är hur lätt det är att göra mallbaserat så att man lätt kan göra egna mallar?"

Jodå.

Menar du mallar som i styckeformat så finns det stöd för det. Definiera ett styckeformat i dokumentets header, starta ett textstycke och sätt textstycket till ett visst styckeformat, så vips så har du styckeformatterat ett stycke. Sedan kan du ändra styckeformatets alla inställningar efter allsköns lust om du vill.

Menar du mallar som i mallar som man stoppar in egna saker i så går det också. I ett projekt som jag donar med nu så behövdes en RTF-export, och jag valde tekniken att sätta in texten i en mall eftersom det var det enklaste och snabbaste sättet.

Grundsyntaxen i RTF är bedrägligt enkel. Du har { och } som inleder block med något som bäst motsvarar scope i c-språken. Du har kontrollord som består av / följt av kontrollordets namn, eventuellt följt av någon form av sifferargument och eventuellt följt av ett mellanslag, och de gäller från då och tills vidare. Allt annat är text. Till exempel så inleder kontrollordet /b1 fetstil, och det pågår tills man hittar en /b0 som avslutar det, kommer till slutet på ett block (dvs }) eller stöter på ett annat kontrollord som återställer formaten (till exempel /pard, för "paragraph definition").

 

[Dante]

Bra idé ...

»En tanke är att exportera i ren text, med markörer som markerar rubrik och sånt. Dessa markörer borde man ganska lätt kunna göra makros för att byta ut mot verklig formatering i de flesta verktyg.«

Just så skulle jag ha gjort (men jag är ju bara formgivare, så vad vet jag).
Styckeformat kräver bara en startmarkör medan teckenformat även kräver en slutmarkör.
Problem kommer dock att uppstå vid tabeller, eftersom alla layoutprogram behandlar dem på olika sätt.

- - -

Ovanstående skulle till exempel kunna se ut så här i InDesign Tagged Text-format (bortsett från att hakparenteserna egentligen ska vara vinkelparenteser):

<font face="courier">[pstyle:brödtext][cstyle:kursiv]»En tanke är att exportera i ren text, med markörer som markerar rubrik och sånt. Dessa markörer borde man ganska lätt kunna göra makros för att byta ut mot verklig formatering i de flesta verktyg.«[cstyle:]
[pstyle:brödtext]
[pstyle:brödtext]Just så skulle [cstyle:halvfet]jag[cstyle:] ha gjort (men jag är ju bara formgivare, så vad vet jag).
[pstyle:brödtext med indrag]Styckeformat kräver bara en startmarkör medan teckenformat även kräver en slutmarkör.
[pstyle:brödtext med indrag]Problem kommer dock att uppstå vid tabeller, eftersom alla layoutprogram behandlar dem på olika sätt.</font face>

 

[Troberg]

Re: RTF

Menar du mallar som i styckeformat så finns det stöd för det.

Jag menar att användaren själv ska kunna knappa in mallen som en textfil (plus eventuellt en för filhuvud/filavslutning), med något slags markörer där data sedan ska skjutas in (naturligtvis med några färdiga mallar man kan utgå från). Programmet läser mallen, skjuter in data med enkel sök-ersätt och matar ut den ämne för ämne till en exportfil.

Samma tankegång som jag hade när jag skapade TPL-formatet för min webserver.

Grundsyntaxen i RTF är bedrägligt enkel. Du har { och } som inleder block med något som bäst motsvarar scope i c-språken. Du har kontrollord som består av / följt av kontrollordets namn, eventuellt följt av någon form av sifferargument och eventuellt följt av ett mellanslag, och de gäller från då och tills vidare. Allt annat är text. Till exempel så inleder kontrollordet /b1 fetstil, och det pågår tills man hittar en /b0 som avslutar det, kommer till slutet på ett block (dvs }) eller stöter på ett annat kontrollord som återställer formaten (till exempel /pard, för "paragraph definition").

Låter ju vettigt. Som det ser ut nu så är nog RTF det vettigaste alternativet.

Får jag fråga varför du hade med formuleringen "bedrägligt enkel"?

 

[Troberg]

Re: Bra idé ...

Problem kommer dock att uppstå vid tabeller, eftersom alla layoutprogram behandlar dem på olika sätt.

Tabeller kommer jag troligen att hålla utanför ändå. Jag gillar inte riktigt det, men det är så förbaskat struligt att fixa så att man kan skicka in tabeller i löptext. Man får helt enkelt stå ut med att ha tabeller och illustrationer utanför (eventuellt kanske man ska kunna bifoga dem till ett avsnitt, och sedan låta mallarna avgöra vad som ska göras av dem).

Ovanstående skulle till exempel kunna se ut så här i InDesign Tagged Text-format (bortsett från att hakparenteserna egentligen ska vara vinkelparenteser):

Ungefär så hade jag tänkt mig, fast jag kanske skulle föredra abstrakta markörer i stil med 'Rubrik' i stället. Då kan mottagande programmet själv välja hur det vill presentera det.

Tanken är ju inte att mitt prog ska leverera en färdig layout, utan snarare att det ska finnas den information som krävs för att göra en grundlayout. I slutänden måste man ändå justera sådant som sidbrytningar och liknande manuellt i vilket fall.

Eftersom jag hade tänkt göra exporten mallbaserad så skulle man mycket väl kunna exportera med egna taggar, eller som tex HTML om man bara vill läsa på skärmen med webbrowser som läsare.

 

[Krille]

Re: RTF

"Jag menar att användaren själv ska kunna knappa in mallen som en textfil (plus eventuellt en för filhuvud/filavslutning), med något slags markörer där data sedan ska skjutas in (naturligtvis med några färdiga mallar man kan utgå från)."

Du får vara petig med felkontrollen av { och } - om de inte matchas så kommer de flesta ordbehandlare helt enkelt att vägra att öppna filen. Eller komma på ett malltaggsystem, som görs om till RTF på lämpligt felsäkert sätt.

"Får jag fråga varför du hade med formuleringen "bedrägligt enkel"?"

Jag trodde att det skulle ta mig en vecka för att lära mig RTF såpass bra att jag skulle lösa uppgiften. Det tog någon dag.

 

[Troberg]

Re: RTF

Du får vara petig med felkontrollen av { och } - om de inte matchas så kommer de flesta ordbehandlare helt enkelt att vägra att öppna filen. Eller komma på ett malltaggsystem, som görs om till RTF på lämpligt felsäkert sätt.

Eller så skickar jag med några exempelmallar och om användaren editerar dem så att de inte funkar så får han/hon skylla sig själv och rätta till det.

Jag trodde att det skulle ta mig en vecka för att lära mig RTF såpass bra att jag skulle lösa uppgiften. Det tog någon dag.

Är det inte bedrägligt svårt om det är enklare än vad man trodde?

 

[Oldtimer]

Japp, men jag fick snabbt allergiska utslag av det eviga tjatet om XML.

Jag förstår dig inte riktigt. Det du beskriver är ju som klippt och skuret för XML. Vad är problemet? Förutom dina allergiska utslag...

/Mikael

 

[Troberg]

Jag förstår dig inte riktigt. Det du beskriver är ju som klippt och skuret för XML. Vad är problemet? Förutom dina allergiska utslag...

Jag gillar det inte på det hela taget. Vill man ha liknande format så föredrar jag EBML. I det här specifika fallet så är problemet att jag inte vill lägga restriktioner på texten, vilket innebär att visst textinnehåll skulle kunna ställa till det (tex om den innehåller taggar).

 

[Oldtimer]

Jag gillar det inte på det hela taget. Vill man ha liknande format så föredrar jag EBML.

Varför då? EBML är (förutom ett betydligt mindre moget format) i första hand ett format för binärdata. Det är ju inspirerat av XML, fast för binärdata istället för textdata. Och det är ju textdata vi pratar om här, eller? Så varför välja ett binärformat?

I det här specifika fallet så är problemet att jag inte vill lägga restriktioner på texten, vilket innebär att visst textinnehåll skulle kunna ställa till det (tex om den innehåller taggar).

Alla textformat som innehåller någon slags märkning, innebär ju att vissa tecken har en speciell innebörd och måste specialhanteras (escaping). Till exempel i RTF, som diskuterades innan, används ju '{', '}' och '/' som styrtecken. Hur hade du tänkt dig att lösa det helt utan styrtecken?

Du tyckte ju att Dantes förslag var bra:

Ungefär så hade jag tänkt mig, fast jag kanske skulle föredra abstrakta markörer i stil med 'Rubrik' i stället.

Hur skulle dina "abstrakta markörer" se ut? Som en XML-tag, kanske? Eller?

Är det jag som inte alls förstår vad du tänker eller är det du som inte förstått XML?

Framför allt, är vi alldeles OT nu (igen)?

/Mikael

 

[Troberg]

Varför då? EBML är (förutom ett betydligt mindre moget format) i första hand ett format för binärdata. Det är ju inspirerat av XML, fast för binärdata istället för textdata. Och det är ju textdata vi pratar om här, eller? Så varför välja ett binärformat?

För att då vet jag att jag hanterar rubbet, även mysko teckenuppsättningar. Hanterar man binärdata hanterar man allt, aldrig några problem och oftast mycket enklare och effektivare att parsa.

Alla textformat som innehåller någon slags märkning, innebär ju att vissa tecken har en speciell innebörd och måste specialhanteras (escaping). Till exempel i RTF, som diskuterades innan, används ju '{', '}' och '/' som styrtecken. Hur hade du tänkt dig att lösa det helt utan styrtecken?

Jo, men vissa format är struligare än andra. Det enklaste och som inte kräver någon märkning är ett textformat i stil med:

Fältnamn xx
Innehåll
Mer innehåll

Där xx är antal rader i fältet. Lite klumpigt, men kan parsas rakt av utan att man behöver en tillståndsmaskin.

Jag kan iofs erkänna att jag inte brytt mig om att kolla hur man hanterar specialtecken i XML, i och med att jag inte använder det (det är så fruktansvärt segt och ineffektivt att parsa, och ska man parsa det korrekt så blir olika teckenuppsättningar en pest att hålla rätt på, i och med att man inte låst vilken som ska användas).

Hur skulle dina "abstrakta markörer" se ut? Som en XML-tag, kanske? Eller?

Nej, inte som en XML-tag. Antagligen skulle jag göra som jag gjorde i TPL och låta användaren själv välja hur de ska se ut.

Så här ser tex TPL-filen som min webserver använder för att eka en request:

(Edit: Forumet gillade inte taggarna. Tar bort koden, du får helt enkelt lita på mig.)

Jag ska ändra några detaljer i formatet för att snabba upp det, men i princip så håller det. Hoppas förresten att forumet inte klipper alla taggar...

Är det jag som inte alls förstår vad du tänker eller är det du som inte förstått XML?

Jag har inte gått in på djupet i det, jag konstaterade att även om man fixat de värsta buggarna från föregångaren (Part 21) så lider det av samma problem som HTML. Det är för ineffektivt, så jag använder inte det. Eftersom jag inte använder det så finns det ingen anledning att gå djupare. Hade de gjort formatet effektivare ur hastighetssynpunkt och minneshantering, samt låtit det hantera binärdata så hade det varit intressant. Nu är det bara sämre än de dussintals andra vedertagna format som funnits i åratal.

Framför allt, är vi alldeles OT nu (igen)?

Nej, faktiskt inte i den här tråden!

 

[Oldtimer]

För att då vet jag att jag hanterar rubbet, även mysko teckenuppsättningar. Hanterar man binärdata hanterar man allt, aldrig några problem och oftast mycket enklare och effektivare att parsa.

Men det du vill hantera här är ju just text. Inte binärkodade heltal eller flyttal. Och text är ju text, speciellt när både EBML och XML utgår ifrån Unicode i UTF-8. Och inte sjutton blir det enklare att parsa ett binärformat.

Lite klumpigt, men kan parsas rakt av utan att man behöver en tillståndsmaskin.

Jo, du får en tillståndsmaskin även här. Jag kan se åtminstone fyra olika tillstånd under parsning.

Jag kan iofs erkänna att jag inte brytt mig om att kolla hur man hanterar specialtecken i XML, i och med att jag inte använder det

De fyra tecken som behöver hanteras speciellt är 'mindre än', 'större än', 'citattecken' och 'apostrof'. De kodas i textströmmen som '<', '>', '"' och '&apos;'. Dessutom behöver ju 'ampersand' själv kodas (till '&') eftersom den inleder dessa sekvenser. Svårare än så är det inte. Och det dräller av XML parsers som redan sköter detta.

(det är så fruktansvärt segt och ineffektivt att parsa,

Ursäkta mig? Segt? Ineffektivt? Har du sett på tempot som en bra SAX-parser tuggar sig igenom ett XML-dokument?

och ska man parsa det korrekt så blir olika teckenuppsättningar en pest att hålla rätt på, i och med att man inte låst vilken som ska användas)

Om inte dokumentet anger annat i XML-deklarationen är det Unicode som har använts. Antingen UTF-8 eller, om textströmmen börjar med 0xFF+0xFE eller 0xFE+0xFF, UTF-16. Det är absolut ingen pest att hålla rätt på, utan väldigt rakt på sak. XML rekommendationen kräver dessutom bara förståelse för UTF-8 och UTF-16 av en parser.

Jag har inte gått in på djupet i det, jag konstaterade att även om man fixat de värsta buggarna från föregångaren (Part 21) så lider det av samma problem som HTML. Det är för ineffektivt,

Jag har tyvärr ingen aning om vad du menar med "part 21". Anfadern till XML heter, mig veterligen, SGML. Och XML har inte samma problem som HTML eftersom det ställer helt andra krav på formatet. Dessutom är HTML i princip bara en buggad applikation av XML (som i och med XHTML blivit en korrekt applikation).

så jag använder inte det. Eftersom jag inte använder det så finns det ingen anledning att gå djupare. Hade de gjort formatet effektivare ur hastighetssynpunkt och minneshantering,

Jag tror du skulle må bra av att titta lite närmare på XML. Formatet lämpar sig utmärkt för mycket höga bearbetningshastigheter och hur du menar att dataformatet skulle leda till någon viss (undermålig) minneshantering förstår jag inte alls.

samt låtit det hantera binärdata så hade det varit intressant.

Det kan hantera binärdata också (till exempel i base64), men i ditt fall var det ju text som skulle hanteras, så varför ser du detta som ett krav?

Nu är det bara sämre än de dussintals andra vedertagna format som funnits i åratal.

Att det, totalt sett, är sämre är en åsikt som jag inte delar. Dessutom är XML betydligt mer vedertaget än de flesta dataformat och har funnits som en standard (egentligen rekommendation) i snart sex år.

Som sagt - titta på XML. Jag tror det lönar sig för dig.

/Mikael - känner sig ändå en aning OT

 

[Troberg]

Men det du vill hantera här är ju just text. Inte binärkodade heltal eller flyttal.

Nej, men i en framtid så kan det mycket väl tänkas att jag vill ha bilder.

Och text är ju text, speciellt när både EBML och XML utgår ifrån Unicode i UTF-8.

Säker på det? Jag har för mig att man får använda andra, bara man talar om det i huvudet. Då blir det genast struligare. Ska man dessutom blanda ihop det med olika internetprotokoll (vilket också eventuellt ligger i röret, om inte annat för att kunna utnyttja bitar från andra projekt) så är det ANSI (eller ibland ASCII) som gäller.

Och inte sjutton blir det enklare att parsa ett binärformat.

Jupp. De är specade ner på enskilda bits. Textformat är ofta lite luddiga i kanterna, på ett sett som binärformat inte brukar vara. Binärformaten har dessutom fördelen att de inte inbjuder till manuell manipulation, vilket gör dem stabilare. En vettig textfil är iofs inte svår att parsa, men en binärfil är nästan alltid lättare.

Jo, du får en tillståndsmaskin även här. Jag kan se åtminstone fyra olika tillstånd under parsning.

Visst, du kan bygga den så. Du kan också läsa den rakt av och tolka raderna efter hand. Formellt sett bor det en tillståndsmaskin där också, men i praktiken är den bara tre variabler som lätt ajourhålls.

Att parsa en XML-fil är betydligt omständigare. Man måste först hitta hakarna för taggarna, sedan parsa ut vilken tagg det är, sedan hitta motsvarande sluttag och parsa ut den. Eftersom man kan bygga upp en hierarki inom formatet kan det dessutom vara så illa att i värsta fall kan man inte ens spara undan (eller vad man nu vill göra) första fältet förrän allt annat har lästs. Part21 var värre, där var ordningen inte alls specificerad, så där måste man bygga upp enorma strukturer i minnet om ifall att man senare skulle få en referens till ett tidigare fält. Jag har varit tvingad att skicka dataset med miljontals poster som Part21, och det har avskräckt mig från hela den protokollfamiljen. XML har fixat det värsta, men den lider till viss del av samma brister.

Att båda dessutom saknar styrning för sådant som radbrytningar och andra whitespaces gör det ännu struligare, eftersom de flesta programspråk föredrar att läsa radorienterat, alternativt måste man läsa blockvis och ha separat logik för att hantera blockskarvar, vilket brukar soppa till logiken en del.

Och det dräller av XML parsers som redan sköter detta.

Japp. Och de är fruktansvärt långsamma. Dessutom vill jag inte förlita mig på en extern komponent (med alla de problemkällor det innebär) för något så simpelt och grundläggande som filformatshantering.

Ursäkta mig? Segt? Ineffektivt? Har du sett på tempot som en bra SAX-parser tuggar sig igenom ett XML-dokument?

Japp. Har du sett mina parsers?

Inneffektivitet är dessutom inte bara en fråga om hastighet. Det är också en fråga om effektiv minnesanvändning och minimal processoranvändning. De XML-parsers jag testat har (med ett tillräckligt stort dataset) gjort en enorm hit på processorlasten (i princip 100%), där traditionella filformat har lästs 5-10 gånger snabbare och aldrig dragit processorn över 25%. Det är många resurser som ska hushållas.

Om inte dokumentet anger annat i XML-deklarationen är det Unicode som har använts. Antingen UTF-8 eller, om textströmmen börjar med 0xFF+0xFE eller 0xFE+0xFF, UTF-16. Det är absolut ingen pest att hålla rätt på, utan väldigt rakt på sak. XML rekommendationen kräver dessutom bara förståelse för UTF-8 och UTF-16 av en parser.

Mao, anything goes och parsern måste förstå det om man ska vara säker. Att man bara rekommenderar UTF spelar inte så stor roll så länge annat kan förekomma.

Jag har tyvärr ingen aning om vad du menar med "part 21". Anfadern till XML heter, mig veterligen, SGML. Och XML har inte samma problem som HTML eftersom det ställer helt andra krav på formatet.

Part21 var ett annat misslyckat försök till ett standardiserat dataformat. För att rätta till det så skapades Part26 (eller Part28?), vilket sedan antingen bytte namn till SGML eller utvecklades till SGML (osäker på vilket).

XML delar en del av problemen med HTML (onödigt krånglig syntax ur parsningssynpunkt, inga styrda radbrytningar mm), men jag håller med om att mycket fixats.

Dessutom är HTML i princip bara en buggad applikation av XML (som i och med XHTML blivit en korrekt applikation).

Jag tror att du kan korta den meningen till "Dessutom är HTML i princip bara en buggad applikation"...

När det gäller HTML så skulle jag dessutom verkligen vilja se ett kompilerat och optimerat format. Det skulle ge SÅ mycket mer utrymme på internet!

Jag tror du skulle må bra av att titta lite närmare på XML. Formatet lämpar sig utmärkt för mycket höga bearbetningshastigheter och hur du menar att dataformatet skulle leda till någon viss (undermålig) minneshantering förstår jag inte alls.

Prova att verkligen stresstesta det.

När det gäller minneshantering så hänger det på långa, oupplösta referenser. Ta följande exempel (parenteser i stället för hakar för att undvika strul, bantat för att jag är för lat för att skriva):

(Mätplats)
(Mätning)
(Fordon)
;Fordonsdata här
(/Fordon)
(Fordon)
;Fordonsdata här
(/Fordon)
;Mätningsdata här
(/Mätning)
(Mätning)
(Fordon)
;Fordonsdata här
(/Fordon)
(Fordon)
;Fordonsdata här
(/Fordon)
;Mätningsdata här
(/Mätning)
(/Mätplats)

Ett helt giltigt exempel. Tänk dig när du har tusentals mätningar, med tiotusentals fordon i varje. Du kan inte avsluta mätningen förrän fordonen är klara, du kan inte avsluta mätplats förrän alla mätningar är klara. Du ser vart det är på väg, och detta är ändå ett enkelt exempel.

Det kan hantera binärdata också (till exempel i base64), men i ditt fall var det ju text som skulle hanteras, så varför ser du detta som ett krav?

Base64 är ju så ineffektivt att man får ont i magen. yEnc är lite bättre, men fortfarande bara en nödlösning.

Att det, totalt sett, är sämre är en åsikt som jag inte delar. Dessutom är XML betydligt mer vedertaget än de flesta dataformat och har funnits som en standard (egentligen rekommendation) i snart sex år.

Det kanske är bättre än vart och ett av de andra för sig, men välj rätt format för rätt tillämpning och då har du alltid en bättre kandidat. Hur vedertaget det är kan ju alltid diskuteras, men jag tyckar att tex gamla hederliga CSV eller TSV är lika vedertagna. Det spelar dessutom inte så stor roll om det är ett internt format.

Som sagt - titta på XML. Jag tror det lönar sig för dig.

Har tittat på det. Det klarar inte de tekniska krav jag ställer.

Mikael - känner sig ändå en aning OT

Bara njut av känslan!