Binaerdaten in XML

[falk]

Hallo liebe Gemeinde,

ich schreibe in VBScript Artikeldaten in ein XML-File. Nix aufregendes bis dahin...

Ich will/muss Binaerdaten (in dem Falle sind's Bilder) mit in die XML-Files schreiben. Auch noch nicht so aufregend... ich schreibe die halt base64-encoded ins XML.

Was mir aber nicht wirklich klar ist - und leider auch durch googlen nicht klarer geworden ist: Es muss doch auch irgendeine halbwegs standardisierte Form geben, wie ich dem Node mit auf dem Weg gebe, als was (also schlicht: der Dateiname...) das b64-encodete Gewusel auf der Gegenseite wieder ausgepackt werden soll.

cul,
Falk

[Rafael]

Der Dateiname sagt darüber ja eigentlich noch nicht viel. Aber unterteile den Knoten doch einfach noch in einige Abschnitte, in denen du dann Informationen wie Mime-Typ und Dateiname neben der Datei selbst einfügst?

[Falk]

Der Dateiname sagt darüber ja eigentlich noch nicht viel. Aber unterteile den Knoten doch einfach noch in einige Abschnitte, in denen du dann Informationen wie Mime-Typ und Dateiname neben der Datei selbst einfügst?

...klar, das bleibt mir ja immer noch, ist aber IMHO nicht der Sinn der Sache, weil man der verarbeitenden Software dann ja auf irgendeinem anderen Wege mitteilen muss, was mit den Binaerdaten zu passieren hat...

Ich denke/hoffe, es gibt irgendeinen Standard, den alle Parser akzeptieren und der so ähnlich aussieht wie in NNTP-Postings oder in Mails eingebettete b64-encodete Anhaenge. Also etwas in der Art...

------_=_NextPart_001_01C396E2.85361DFC
Content-Type: image/gif;
name="image001.gif"
Content-Transfer-Encoding: base64

cul,
Falk

[Der Martin]

Hallo,

Ich will/muss Binaerdaten (in dem Falle sind's Bilder) mit in die XML-Files schreiben. Auch noch nicht so aufregend... ich schreibe die halt base64-encoded ins XML.

meiner Ansicht nach nicht wirklich optimal, aber eine bessere Möglichkeit haben wir wohl nicht.

Was mir aber nicht wirklich klar ist - und leider auch durch googlen nicht klarer geworden ist: Es muss doch auch irgendeine halbwegs standardisierte Form geben, wie ich dem Node mit auf dem Weg gebe, als was (also schlicht: der Dateiname...) das b64-encodete Gewusel auf der Gegenseite wieder ausgepackt werden soll.

Was spricht dagegen, diese Informationen als Attribute an das umgebende Containerelement zu klatschen?

<binary filename="background.jpg" mimetype="image/jpeg">
    76HDF725HJAFBGWZ8E5ZSYR8ATZHGHGAHF4T5IO9SHYLZU
    GF850E4ND74O3KSW03HWTXC75KZJNI8XB9GHDWTIOZ ...
   </binary>

So long,
 Martin

[Falk]

[...]

Was spricht dagegen, diese Informationen als Attribute an das umgebende Containerelement zu klatschen?

<binary filename="background.jpg" mimetype="image/jpeg">
    76HDF725HJAFBGWZ8E5ZSYR8ATZHGHGAHF4T5IO9SHYLZU
    GF850E4ND74O3KSW03HWTXC75KZJNI8XB9GHDWTIOZ ...
   </binary>

So long,
Martin

...dagegen spricht nichts. Wwenn das funktioniert. Sprich: Wenn die Parser damit was anfangen können...

Mein Problem ist: Ich habe keinen wirklichen Einfluss darauf, wie die XMLs auf der Gegenseite verarbeitet werden. Der ganze Kram - ich dürfte da XMLs von etlichen 100 MB produzieren...;) - dient dazu, die Daten möglichst deppengerecht für Verlage bereitzustellen, die den Kram dann mit einer Transformation für InDesign aufbereiten.

Die eingebetteten Bildchen müssen bei der Verarbeitung extrahiert werden, zweifelsfrei nach den Angaben im XML benannt werden, auf das die den Fotoworkflow via OPI gehen und erst wieder bei der Plattenbelichtung zu den verbalen Inhalten aus dem XML zurückfinden...;)

Vielleicht sollte ich mir den Kram aber auch einfach sparen, die Bildchen als Files in ein Archiv packen, das XML mit Verweisen zu den Bilddateinamen mit ins Archiv packen und mir einfach keine Gedanken machen, wie der Rest weitergeht...;)

cul,
Falk

[Falk]

Hallo liebe Gemeinde,

danke fuer die Anregungen, ich haette gleich mal auf die Hilfeseiten meines bevorzugten XML-Editors gehen sollen...;-)

http://www.stylusstudio.com/binary_xml.html

cul,
Falk

[Tim Tepaße]

Hallo Falk,

Es muss doch auch irgendeine halbwegs standardisierte Form geben, wie ich dem Node mit auf dem Weg gebe, als was (also schlicht: der Dateiname...) das b64-encodete Gewusel auf der Gegenseite wieder ausgepackt werden soll.

Du hast zwar schon was gefunden, trotzdem noch meine Empfehlung: Ich würde spontan zu Data URIs greifen, auch Base64-Kodierung, natürlich, aber es ist ein standardisiertes Schema inklusive MIME Media Typen des kodierten Inhaltes. Wenn man viel Interoperabilität will, ist das vielleicht nett.

Tim

[Daniel Thoma]

Hallo falk,

Im Grunde hast Du gerade entdeckt, wie XML Funktioniert.
XML-Elemente haben nunmal zunächst keinerlei Semantik. Nicht mal die eine "dieses Element enthält Binärdaten".
XML-Schema hat nun anscheinend einen Typ für base64-Kodierte Daten. Das zu verwenden falls Du ein Schema hast, ist sicher sinnvoll, allerdings hilft es Dir erstmal nicht viel weiter, da die Parser die Binärdaten deswegen noch lange nicht verarbeiten können.
Der von dir verlinkte Editor stellt nun wohl proprietäre XSLT-Funtionen bereit, um das zu erledigen. Damit verlangst Du aber vom Empfänger der Daten genau so, dass er das verwendet oder selber weiß, was er damit tun soll.

Für weitere Metainformation (Dateiname, Mime-Type) musst Du Dir ohnehin etwas überlegen. In der von Dir verlinkten Lösung ist das ja schlicht durch das XSLT-Stylesheet implementiert.
Die von Tim vorgeschlagenen Data-URLs halte ich für einen relativ vernünftigen Ansatz, da das immerhin eine standardisierte Darstellung ist, wenn auch ein XML-Parser ebenfalls nichts damit anfangen kann.

Grüße

Daniel

[Falk]

Hi Daniel,

Im Grunde hast Du gerade entdeckt, wie XML Funktioniert.

Noeh, ist schon ein paar Tage her. Binaerdaten versuche ich allerdings sehr wohl zum erstenmal da hinein zu packen.

XML-Elemente haben nunmal zunächst keinerlei Semantik. Nicht mal die eine "dieses Element enthält Binärdaten".

...als Du Dein XML-Wissen mit der Muttermilch bekommen hast, gab es bspw. auch noch keine Schemata, die ich eigentlich immer verwende, seit die gegenüber DTDs so viel feinere Vorgaben ermöglichen. Dass Nodes in der simpelsten denkbaren Form von XML keine typbeschreibende Semantik haben, ist schon klar. Es soll aber so etwas wie Entwicklung - an der Stelle notfalls meinetwegen auch proprietaer - geben. Und genau darauf zielte die Frage. Wenn ich Zeit und Lust haette, wuerde ich mir wohl jetzt mal die open-office-Spezifikation zu Gemuete fuehren; da wird genau so etwas ja wohl mit Sicherheit benoetigt...

Der von dir verlinkte Editor stellt nun wohl proprietäre XSLT-Funtionen bereit, um das zu erledigen. [...]

...nee, er stellt einen in Java implementierten Adapter bereit, um damit Daten on the fly ins Filesystem zu schreiben.

Für weitere Metainformation (Dateiname, Mime-Type) musst Du Dir ohnehin etwas überlegen. In der von Dir verlinkten Lösung ist das ja schlicht durch das XSLT-Stylesheet implementiert.

Wie geschrieben: der Adapter ist das eigentlich coole. Schade nur, dass die Parser selbst so etwas nicht enthalten.

[...]
cul,
Falk

[Daniel Thoma]

Hallo Falk,

Im Grunde hast Du gerade entdeckt, wie XML Funktioniert.
...als Du Dein XML-Wissen mit der Muttermilch bekommen hast,

Die Formulierung von mir war nicht Arrogant gemeint, also kein Grund sich aufzuregen ;-)
Ich wollte nur darauf hinweißen, dass der Empfänger der Daten nunmal wissen muss, was er damit machen soll (mit und ohne Schemata).

Und genau darauf zielte die Frage. Wenn ich Zeit und Lust haette, wuerde ich mir wohl jetzt mal die open-office-Spezifikation zu Gemuete fuehren; da wird genau so etwas ja wohl mit Sicherheit benoetigt...

Ohne das Open Document Fromat genau zu kennen, würde ich sagen, dass sie das nicht brauchen. OO-Dokumente sind nicht nur XML sondern Zip-Dateien, die neben den XML-Dateien für das Dokument auch noch Bilder u.ä. direkt enthalten. Diese können also einfach referenziert werden. Das ist sowieso die elegantere Lösung, wenn sie denn Umsetzbar ist. Allein schon deshalb, weil base64 die Daten ganz gut aufbläst.

Wie geschrieben: der Adapter ist das eigentlich coole. Schade nur, dass die Parser selbst so etwas nicht enthalten.

Ach jetzt sehe ich erst richtig, was die machen. Die geben bei result-dcument eine Url an, die dann wohl diesen Adapter anstößt. Ok ein Netter Hack, aber erst recht eine Proprietäre Lösung, da XSLT dieses Konzept ja fremd ist.
Es sollte allerdings nicht so schwierig sein, das mit beliebigen anderen XSLT-Prozessoren auch zu implementieren. Üblicherweise haben diese ja eine Schnittstelle, über die Du beeinflussen kannst, was passiert, wenn eine Datei irgendwo hin geschrieben werden soll. Alternativ sollte es so auch möglich sein, result-document um ein encoding-Attribut o.ä. zu erweitern.

Grüße

Daniel

[Falk]

Hi Daniel,

...als Du Dein XML-Wissen mit der Muttermilch bekommen hast,
Die Formulierung von mir war nicht Arrogant gemeint

...na, kam ein wenig so rüber...;)

...also kein Grund sich aufzuregen ;-)
...ach, was heisst schon aufregen. Ich hab' die letzten flamewars im Fido gehabt, ist also schon paar Jahre her...;) Ausserdem funktionieren wuerde MEINE CAPLOCK-TASTE JA SCHON NOCH...;-)

[...]

Ohne das Open Document Fromat genau zu kennen, würde ich sagen, dass sie das nicht brauchen. OO-Dokumente sind nicht nur XML sondern Zip-Dateien, die neben den XML-Dateien für das Dokument auch noch Bilder u.ä. direkt enthalten. Diese können also einfach referenziert werden. Das ist sowieso die elegantere Lösung, wenn sie denn Umsetzbar ist. Allein schon deshalb, weil base64 die Daten ganz gut aufbläst.

Noeh, wenn der folgende Link noch aktuell ist, werden OODocs zwar als  Zips gespeichert, haben aber alle eingebetteten Grafiken etc als B64 inline... (siehe Publishing mit OpenOffice) Das macht mir das Format aber schon ein wenig suspekt..;)

[...]
...den Adapter finde ich trotzdem eine coole Idee. Wenn ich mal ganz viel Zeit und Lust habe, würde ich mal überlegen, das als Webservice aufzusetzen.

So, um nun mal zu 'nem Ende zu kommen, meine XMLs werden irre gross - ueberschlaegig geschaetzt rund 6 GB fuer reichlich 1500 Artikel...;)

Der Base64-Kram bläht die ungefähr ein Drittel mehr auf als eigentlich noetig. Ich muesste die XMLs also für den Austausch ohnehin zippen. Da kann ich mir den Quatsch auch sparen, schmeisse die Hires-Bildchen mit schoenen eindeutigen UID-Namen gleich mit ins Archiv und referenziere die ordentlich im XML.

Allen vielen Dank, die zum Erkenntnisgewinn beigetragen haben.

Viele Gruesse,
Falk

[Daniel Thoma]

Hallo Falk,

Noeh, wenn der folgende Link noch aktuell ist, werden OODocs zwar als  Zips gespeichert, haben aber alle eingebetteten Grafiken etc als B64 inline...

Scheint nicht mehr aktuell zu sein. Hab gerade mal so eine Datei entpackt und nachgeguckt.
Ein eingefügtes Bild sieht so aus:
<draw:image xlink:href="Pictures/1000000000000A2000000798E8E2296D.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
Referenziert wird also per XLink, wenn man beim Einfügen "Verknüpfen" angibt, steht da der Pfad zur Originaldatei. So ist es ein Pfad im gleichen Archiv. Die Datei liegt da dann auch tatsächlich.

Auch wenn man das als OO-1.0-Dokument speichern lässt, passiert das. Einziger unterschied ist, dass der Pfad mit einem # beginnt. Keine Ahnung, auf welche Openoffice-Version sich der Artikel bezieht, aber irgendwann wird das dann wohl mal so gewesen sein.

Grüße

Daniel