Meinung: Dateiformat für Gästebuch? (Flatfile)
Felix Riesterer
Meinung: Dateiformat für Gästebuch? (Flatfile)
Felix Riesterer
Liebes Forum,
in meinem momentanen XML-Rausch habe ich beschlossen, das Datenformat meiner Gästebuch-Daten auf XML umzustellen. Ich fand schon immer, dass ein GB die Verwendung einer Datenbank nicht unbedingt rechtfertigt und bin ein Verfechter einer Flatfile-Lösung für GBs. Dabei habe ich mir Gedanken über eine passende DTD gemacht. Hier mein Ergebnis:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<!DOCTYPE gaestebuch [
<!ELEMENT gaestebuch (eintrag)+>
<!-- definiert das Grundgerüst des Dateiformates -->
<!ELEMENT eintrag (autor, nachricht)>
<!-- definiert den Aufbau eines GB-Eintrags -->
<!ATTLIST eintrag
datum CDATA #REQUIRED
zeit CDATA #REQUIRED
>
<!ELEMENT autor (#PCDATA)>
<!-- definiert den Aufbau der Daten über den Autor eines Eintrags -->
<!ATTLIST autor
email CDATA #IMPLIED
homepage CDATA #IMPLIED
icq CDATA #IMPLIED
aim CDATA #IMPLIED
yim CDATA #IMPLIED
msn CDATA #IMPLIED
>
<!-- Die Zusatzdaten zum Autor werden in diesen Attributen gespeichert -->
<!ELEMENT nachricht (#PCDATA | br)*>
<!-- definiert den Aufbau der Daten für die Nachricht -->
<!ELEMENT br EMPTY>
<!-- Zeilenumbruch: leeres Element -->
]>
<gaestebuch>
<eintrag datum="24.12.2005" zeit="18:00">
<autor email="gb_tester@mail.de" homepage="http://www.meine-hp.de" icq="123456789" aim="" yim="" msn="">ein Tester</autor>
<nachricht>Hallo,<br />viele Grüße!</nachricht>
</eintrag>
</gaestebuch>
Leichtes Kopfzerbrechen bereiten mir noch Zeilenumbrüche, die ich mit <br /> zu realisieren versuche. Der Validator mag diese Datei (wenn vom Webspace aus validiert) als gültiges XML1.0, aber ob das mit den Umbrüchen nicht besser geht...? Wenn ich da in HTML an das <pre>-Element denke, da werden ja Zeilenumbrüche durchaus berücksichtigt. Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Was meint ihr dazu?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
hallo Felix,
interessante Fragestellung, die du da augeworfen hast. Ich ziehe mal nur einen allgemeinen Aspekt heraus, ohne auf deine konkrete Frage einzugehen ('tschldigung, das macht etwas mehr Mühe, folgt aber möglicherwiese noch, wenn mir was dazu einfällt).
Ich fand schon immer, dass ein GB die Verwendung einer Datenbank nicht unbedingt rechtfertigt und bin ein Verfechter einer Flatfile-Lösung für GBs.
Der seit einiger Zeit anhaltende "Hype" bei der Verwendung von Datenbanken ist ja auch darin begründet, daß mySQL fast überall zur Verfügung gestellt wird. Man kann es meines Erachtens nicht oft genug betonen, daß bei einem Gästebuch, in dem nicht wesentlich mehr als vielleicht drei Einträge pro Tag zu erwarten sind, eine Datenbank tatsächlich nicht zwingend nötig für die "Daenhaltung" ist. XML kann das in diesem Fall auch, wird aber von den "gängigen" Script-Archiven, aus denen sich ja viele bedienen, so gut wie nie benutzt. "Man" nimmt halt ein PHP-Script, knallt die möglichen Einträge in eine DB, und gut ist. Letzten Endes waltet bei diesem leider sehr verbreiteten Vorgehen so gut wie keine "Energie des Verstehens".
Dein posting wäre eine gute Gelegenheit, eventuell mal zu diskutieren, wann, wo und vor allem _wie_ Datenhaltung erfolgen kann.
Nein, ich habe nichts gegen Datenbanklösungen und/oder den Einsatz von mySQL. Ich habe nur etwas dagegen, wenn man das als einen "Standard" ansieht und die existierenden Alternativen, die alle Sinn machen, nicht einmal zur Kenntnis nimmt.
Dabei habe ich mir Gedanken über eine passende DTD gemacht.
Auf den ersten Blick sieht diese DTD gut aus.
<!ELEMENT nachricht (#PCDATA | br)*>
<!-- definiert den Aufbau der Daten für die Nachricht -->
<!ELEMENT br EMPTY>
<!-- Zeilenumbruch: leeres Element -->Leichtes Kopfzerbrechen bereiten mir noch Zeilenumbrüche, die ich mit <br /> zu realisieren versuche. Der Validator mag diese Datei (wenn vom Webspace aus validiert) als gültiges XML1.0, aber ob das mit den Umbrüchen nicht besser geht...? Wenn ich da in HTML an das <pre>-Element denke, da werden ja Zeilenumbrüche durchaus berücksichtigt. Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Aus meiner Sicht hast du die Alternativen bereits in deiner Frage benannt. <pre> wäre eine Möglichkeit, nur kannst bisher allein du wissen, ob und wo du dieses Element einsetzen willst.
Grüße aus Berlin
Christoph S.
-
Lieber Christoph,
danke für Deine umfangreiche Antwort!
Dein posting wäre eine gute Gelegenheit, eventuell mal zu diskutieren, wann, wo und vor allem _wie_ Datenhaltung erfolgen kann.
Nein, ich habe nichts gegen Datenbanklösungen und/oder den Einsatz von mySQL. Ich habe nur etwas dagegen, wenn man das als einen "Standard" ansieht und die existierenden Alternativen, die alle Sinn machen, nicht einmal zur Kenntnis nimmt.
Das ist zwar nicht genau der Hintergrund meiner Überlegungen (da ich jetzt nicht an Script-Kiddies und ihre HP-Bastelübungen dachte), aber dieses Thema finde ich reizvoll!
Aus meiner Sicht hast du die Alternativen bereits in deiner Frage benannt. <pre> wäre eine Möglichkeit, nur kannst bisher allein du wissen, ob und wo du dieses Element einsetzen willst.
Das <pre>-Element in HTML hat eine ganz bestimmte Ausgabe im Browser zur Folge. Was mich daran reizt, ist lediglich, dass der Fließtext der Anzeige bei einem Zeilenumbruch im Quelltext _in der Anzeige_ _auch_ _umgebrochen_ wird. So käme ich um eine XML-technische Notation eines Zeilenumbruches herum.
Wie gesagt, den Zeilenumbruch in meiner XML-Datei DTD-konform mit einzubringen ist mir noch nicht ganz geheuer. Besonders interessant wird es, wenn im Fließtext Links enthalten sein sollen, deren anklickbarer Teil nicht mit der URL identisch ist (z.B. so). Diese Möglichkeit ist in meinem GB nicht vorhanden (URLs werden automatisch zu Verweisen konvertiert), aber wenn ein Moderator etwas verlinken möchte, dem er einen abweichenden Linktext gibt, dann muss das ja irgendwie gespeichert werden (BB-Code-Problematik)...
Gibt es eigentlich schon eine fertige Gästebuch-DTD? Wäre mal interessant zu studieren!
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
-
Hallo Freunde des gehobenen Forumsgenusses,
Leichtes Kopfzerbrechen bereiten mir noch Zeilenumbrüche, die ich mit <br /> zu realisieren versuche.
Ich finde, dass in der Datenbank (in diesem Fall halt eine XML-Datei) genau das gespeichert werden
sollte, was der Benutzer eingegeben hat und erst das Ausgabescript so Sachen wie htmlentities
und nl2br erledigen sollte.Gruß
Alexander Brock--
SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:? ss:| de:> js:( ch:| sh:( mo:} zu:}
http://againsttcpa.com-
Lieber Alexander,
Ich finde, dass in der Datenbank (in diesem Fall halt eine XML-Datei) genau das gespeichert werden
sollte, was der Benutzer eingegeben hat und erst das Ausgabescript so Sachen wie htmlentities
und nl2br erledigen sollte.sicherlich ein goldrichtiger Ansatz. Nun ist aber ein HTML-Quelltext in seiner Struktur und in seiner Darstellung unterschiedlich, was gerade bei mehreren aufeinanderfolgenden Leerzeichen, Zeilenumbrüchen und Tabstops spürbar wird. Wenn der User nun einen Zeilenumbruch eingibt, ich den auch so in meine XML-Datei eingebe, dann kann man das im Quelltext zwar sehen, aber Zeilenumbrüche sind in XML wohl (da kann ich jetzt falsch liegen) nicht direkt #PCDATA, oder? Jedenfalls könnten sie beim Parsen verloren gehen. Ich muss das mal testen, bevor ich weiteren Müll schreibe!
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
-
Hi,
ein sinnvoller Einsatz einer XML-Datenbank? Mmh ...
Es handelt sich hier um ein Gastebuch, alle Eintraege werden an's Ende angehangen. Alle? Nein, denn wenn da Unsinn drin steht oder Spam oder anderes soll das natuerlich raus. Bei einem Gaestebuch mit drei Eintraegen pro Tag geht das haendisch, bei mehr waere evt ein Automatismus faellig. Den gibt es vorgefertigt in verschiedene Sprachen. Die XML-Datenbank muss nicht endlos gross werden, da einzelne Teile als Archiv statisch ausgelagert werden koennen. Wird das regelmaessig getan, nach einer bestimmten Zeit/einem bestimmtem Aufkommen, kann die gesamte Datenbank archiviert werden. Das ist zwar etwas brutaler als der Schwanzabschneider hier aber bei einem Gaestebuch durchaus akzeptabel. Es gibt keinerlei Verbindung der Datensaetze, jeder einzelne ist autark.
Also: ein sinnvoller Einsatz einer XML-Datenbank? Ja, durchaus.Aber Du wolltest ja auch Details zu Deiner Aufteilung.
<!ELEMENT gaestebuch (eintrag)+>
Das funktioniert nicht, Du musst bei 0 anfangen.
Oder selber den ersten Eintrag schreiben ;-)Klar kannst Du auch erst bei dem erstem Eintrag die DB anlegen, aber das waere ein unnoetiger Branch.
<!ELEMENT eintrag (autor, nachricht)>
<!-- definiert den Aufbau eines GB-Eintrags -->
<!ATTLIST eintrag
datum CDATA #REQUIRED
zeit CDATA #REQUIRED
>Das Datum beinhaltet normalerweise die Zeit.
Ueblich ist bei sowas das Format aus RFC 822 ('date -R')Ich wuerde auch noch eine laufende Nummer einfuegen, da die Zeit "nur" eine Sekundenaufloesung hat, wenn sie nach RFC 822 dargestellt wird. Ist aber auch nicht wirklich zwingend.
<!ELEMENT autor (#PCDATA)>
Bei allen Eintraegen mit variabler Laenge ist diese zu begrenzen.
Ja, das geht in der DTD nicht, ist mir schon klar ;-)<!-- definiert den Aufbau der Daten über den Autor eines Eintrags -->
<!ATTLIST autor
email CDATA #IMPLIED
homepage CDATA #IMPLIEDJa, das ist nachvollziehbar, aber ...
icq CDATA #IMPLIED
aim CDATA #IMPLIED
yim CDATA #IMPLIED
msn CDATA #IMPLIED... das ist eine unnoetige Begrenzung der Variabilitaet.
Dafuer sollte lieber ein eigenes unspezifisches Element angeboten werden, z.B.<!ELEMENT autor (aname,(aadress)*)>
<!ELEMENT aname (#PCDATA )>
<!ELEMENT aadress EMPTY>
<!ATTLIST aadress
protocol CDATA #REQUIRED
ref CDATA #REQUIRED>So kann jedes, auch zukuenftige Protokoll hinzugefuegt werden. So natuerlich auch die aus irgendwelchen Gruenden so beliebten ikonographischen Bildchen.
Und wenn keiner 'was eintraegt spart's auch Platz.<!ELEMENT br EMPTY>
<!-- Zeilenumbruch: leeres Element -->Tja, das Problem mit den Zeilenumbruechen. Ich wuerd's ebenfalls der Implementation ueberlassen, wie sie damit umgeht.
Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Besser nicht.
so short
Christoph Zurnieden
-
Hallo Christoph.
Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Besser nicht.
Weshalb nicht?
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Lieber Ashura, lieber Christoph,
das mit den Zeilenumbrüchen löse ich per ENTITY.
<!ENTITY zeilenumbruch " "> <!-- "Zeilenumbruch" Windows-kompatibel -->Aber da ich schonmal mit ENTITIES anfange, mir macht das ampersand-Zeichen beim Parsen Probleme. Mein Ansatz war:
<!ENTITY und "&"> <!-- "und"-Zeichen (Ampersand) -->Wenn ich jetzt innerhalb von PHP den XML-Parser darüberlaufen lasse, dann bringt er in jeder Quellzeile, in der mindestens ein
&und;steht, einen Fehler "unclosed token". Was mache ich da falsch?Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Besser nicht.
Weshalb nicht?
Erhoehte Unfallgefahr.
so short
Christoph Zurnieden
-
Hallo Christoph.
Oder könnte ich den Inhalt von <nachricht> als CDATA deklarieren?
Besser nicht.
Weshalb nicht?
Erhoehte Unfallgefahr.
Diese Antwort hilft mir leider noch nicht sonderlich weiter.
Warum sollte ein<!CDATA[Hallo\nWelt]]>eine „erhöhte Unfallgefahr“ darstellen?Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hi,
Erhoehte Unfallgefahr.
Diese Antwort hilft mir leider noch nicht sonderlich weiter.
Sie sollte ja auch mehr zum Selberdenken anregen ;-)
Warum sollte ein
<!CDATA[Hallo\nWelt]]>eine „erhöhte Unfallgefahr“ darstellen?Das hat rein gar nichts miteinander zu tun, das ist eine fallacia conclusiones a dicto secundum quid ad dictum simpliciter: das Du etwas ungefaehrliches gefunden hast heisst ja noch lange nicht, das alles ungefaehrlich ist.
CDATA laesst alles zu, auch eingestreutes Javascript, Mark-up usw. Das abstrakte "Erhoehte Unfallgefahr" fand ich daher passend.so short
Christoph Zurnieden
-
Hallo Christoph.
Erhoehte Unfallgefahr.
Diese Antwort hilft mir leider noch nicht sonderlich weiter.
Sie sollte ja auch mehr zum Selberdenken anregen ;-)
Dachte ich mir, ich wusste nur nicht, in welche Richtung.
Warum sollte ein
<!CDATA[Hallo\nWelt]]>eine „erhöhte Unfallgefahr“ darstellen?Das hat rein gar nichts miteinander zu tun, das ist eine fallacia conclusiones a dicto secundum quid ad dictum simpliciter:
Letzteres heißt auf Deutsch?
das Du etwas ungefaehrliches gefunden hast heisst ja noch lange nicht, das alles ungefaehrlich ist.
Dem schließe ich mich an.
CDATA laesst alles zu, auch eingestreutes Javascript, Mark-up usw. Das abstrakte "Erhoehte Unfallgefahr" fand ich daher passend.
Kann ich nicht nachvollziehen.
Ein<![CDATA[<script type="text/javascript">alert('Hallo Welt');</script>]]>wird von keinem meiner Clients bei der Anzeige ausgeführt. (Wenn ich das betroffene XML-Dokument direkt aufrufe; bei der eigentlichen Ausgabe läuft sowieso htmlspecialchars() über die Daten.)Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hi,
Das hat rein gar nichts miteinander zu tun, das ist eine fallacia conclusiones a dicto secundum quid ad dictum simpliciter:
Letzteres heißt auf Deutsch?
Eine sinngemaesse Uebersetzung kommt nach dem Doppelpunkt.
Eine woertlich Uebersetzung auch noch?"Fehlschluss vom bedingt Gesagtem zum allgemein Gesagtem."
CDATA laesst alles zu, auch eingestreutes Javascript, Mark-up usw. Das abstrakte "Erhoehte Unfallgefahr" fand ich daher passend.
Kann ich nicht nachvollziehen.
Es ist aber so.
Ein
<![CDATA[<script type="text/javascript">alert('Hallo Welt');</script>]]>wird von keinem meiner Clients bei der Anzeige ausgeführt.Fallatia conclusiones ...
Das bei Deinen Klienten nichst passiert heisst nicht, das nirgendwo und unter allen Umstaenden nichts passiert.(Wenn ich das betroffene XML-Dokument direkt aufrufe;
Das ist eine DB, da wird nichts direkt aufgerufen. Somit besteht auch die Gefahr ...
bei der eigentlichen Ausgabe läuft sowieso htmlspecialchars() über die Daten.)
... das genau sowas vergessen wird. Das nenne ich nunmal, und ich glaube auch mit Fug und Recht "erhoehte Unfallgefahr".
so short
Christoph Zurnieden
-
Hallo Christoph.
Eine sinngemaesse Uebersetzung kommt nach dem Doppelpunkt.
Eine woertlich Uebersetzung auch noch?"Fehlschluss vom bedingt Gesagtem zum allgemein Gesagtem."
Danke.
Das bei Deinen Klienten nichst passiert heisst nicht, das nirgendwo und unter allen Umstaenden nichts passiert.
Also gut, das kann ich nachvollziehen.
Somit besteht auch die Gefahr ...
bei der eigentlichen Ausgabe läuft sowieso htmlspecialchars() über die Daten.)
... das genau sowas vergessen wird. Das nenne ich nunmal, und ich glaube auch mit Fug und Recht "erhoehte Unfallgefahr".
Verstehe. Diesbezüglich gehe ich aber immer auf Nummer sicher.
Danke für die Erklärung.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
-
-
-
-
-
-
Lieber Christoph,
Du hast ne Menge guter Gedanken!
<!ELEMENT gaestebuch (eintrag)+>
Das funktioniert nicht, Du musst bei 0 anfangen.
Oder selber den ersten Eintrag schreiben ;-)Stimmt. Aber wer stellt ein GB ins Netz, in dem er keinen Ersteintrag anbietet? Das Plus-Zeichen ist schnell durch einen Asterix ersetzt. :-)
<!ELEMENT eintrag (autor, nachricht)>
<!-- definiert den Aufbau eines GB-Eintrags -->
<!ATTLIST eintrag
datum CDATA #REQUIRED
zeit CDATA #REQUIRED
>
Das Datum beinhaltet normalerweise die Zeit.
Ueblich ist bei sowas das Format aus RFC 822 ('date -R')Das muss ich mal genauer anschauen. Kenne ich noch nicht...
Ich wuerde auch noch eine laufende Nummer einfuegen, da die Zeit "nur" eine Sekundenaufloesung hat, wenn sie nach RFC 822 dargestellt wird. Ist aber auch nicht wirklich zwingend.
Ich denke, es ist völlig überflüssig, da die "laufende Nummer" durch die Reihenfolge der <eintrag>-Elemente definiert ist. Diese Reihenfolge ist ja nicht unerheblich!
icq CDATA #IMPLIED
aim CDATA #IMPLIED
yim CDATA #IMPLIED
msn CDATA #IMPLIED... das ist eine unnoetige Begrenzung der Variabilitaet.
Dafuer sollte lieber ein eigenes unspezifisches Element angeboten werden, z.B.<!ELEMENT autor (aname,(aadress)*)>
<!ELEMENT aname (#PCDATA )>
<!ELEMENT aadress EMPTY>
<!ATTLIST aadress
protocol CDATA #REQUIRED
ref CDATA #REQUIRED>So kann jedes, auch zukuenftige Protokoll hinzugefuegt werden. So natuerlich auch die aus irgendwelchen Gruenden so beliebten ikonographischen Bildchen.
Und wenn keiner 'was eintraegt spart's auch Platz.Diese Überlegung gefällt mir! Allerdings stört mich das leere Element... Aber je mehr ich darüber nachdenke, desto sinvoller erscheint mir das Ganze mit dem leeren Element. Für eine GB-DTD, die universeller sein sollte, als ich das für meine privaten Bedürfnisse bräuchte, müsste diese Flexibilität durchaus haben!
Mal weiter probieren. Danke!
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
Das Datum beinhaltet normalerweise die Zeit.
Ueblich ist bei sowas das Format aus RFC 822 ('date -R')
Das muss ich mal genauer anschauen. Kenne ich noch nicht...Wenn ich hier und jetzt ein 'date -R' ausfuehre bekomme ich das hier:
Wed, 16 Nov 2005 16:07:45 +0100Wochentag (Kurzform), Komma, Leerzeichen(0x20), Tag-im-Monat, Leerzeichen(0x20)Monat (Kurzform), Leerzeichen(0x20), Stunden(24 Stunden System), Doppelpunkt(0x3a), Minuten, Doppelpunkt(0x3a), Leerzeichen(0x20), Sekunden, Leerzeichen(0x20), Pluszeichen(0x2b) oder Minuszeichen(0x2d), vierstellige Differenz zu GMT (ersten zwei Ziffern sind Stunden, letzten zwei Ziffern sind Minuten)
Die Namen sind evt Locale-Abhaengig, bitte in der Beschreibung nachschlagen.
Ich wuerde auch noch eine laufende Nummer einfuegen, da die Zeit "nur" eine Sekundenaufloesung hat, wenn sie nach RFC 822 dargestellt wird. Ist aber auch nicht wirklich zwingend.
Ich denke, es ist völlig überflüssig, da die "laufende Nummer" durch die Reihenfolge der <eintrag>-Elemente definiert ist. Diese Reihenfolge ist ja nicht unerheblich!Die Reihenfolge ist allerdings voellig unerheblich, wenn Du eine laufende Nummer hast. Das koennte von Vorteil sein, wenn Du die DB nicht immer von Hand editieren willst.
So kann jedes, auch zukuenftige Protokoll hinzugefuegt werden. So natuerlich auch die aus irgendwelchen Gruenden so beliebten ikonographischen Bildchen.
Und wenn keiner 'was eintraegt spart's auch Platz.
Diese Überlegung gefällt mir! Allerdings stört mich das leere Element...Wie Du das genau einbaust ist voellig egal, Du kannst natuerlich statt der Attribute auch Elemente nehmen.
Aber je mehr ich darüber nachdenke, desto sinvoller erscheint mir das Ganze mit dem leeren Element. Für eine GB-DTD, die universeller sein sollte, als ich das für meine privaten Bedürfnisse bräuchte, müsste diese Flexibilität durchaus haben!
Naja, viel faellt mir dazu aber nicht mehr ein. Koenntest vielleicht noch eine Signatur erlauben, aber sonst? Ist halt nur ein Gaestebuch, kein Forum.
Zu Deinem "unclosed token" Problem:
Bitte vollstaendige Fehlermeldung
Bitte genuegend Daten zum Nachvollziehen (komplette Datei mit DTDT und allem ist hier wohl noetig. Kannst sie auch verlinken, aber so gross ist sie ja nicht)
Bitte die Namen und Versionen aller Beteiligten (hier reichen wohl PHP und XML-Parser)
Kannst aber auch selber erstmal schauen ob Du alle Anfuehrungszeichen geschlossen hast und auch ob das zweite Fragezeichen im XML-Header nicht fehlt.so short
Christoph Zurnieden
-
Hallo Christoph,
Ueblich ist bei sowas das Format aus RFC 822 ('date -R')
Wed, 16 Nov 2005 16:07:45 +0100Wobei sich im XML-Land eher eine Untermenge des ISO 8601 Zeitformates durchgesetzt hat: http://www.w3.org/TR/NOTE-datetime
Auch die XML Schema Datentypen zum Thema Zeit sind alle davon abgeleitet:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#isoformatsTim
-
Hi,
Ueblich ist bei sowas das Format aus RFC 822 ('date -R')
Wed, 16 Nov 2005 16:07:45 +0100Wobei sich im XML-Land eher eine Untermenge des ISO 8601 Zeitformates durchgesetzt hat: http://www.w3.org/TR/NOTE-datetime
Auch die XML Schema Datentypen zum Thema Zeit sind alle davon abgeleitet:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#isoformatsJa, das ist mir durchaus bekannt, ich finde nur RFC-822 immer noch(!) portabler. Dafuer gibt's es fuer fast alle Sprachen Fertiges. Nur wenn eine Umwandlung per XSL vorgenomen werden soll waere natuerlich der entsprechenden Empfehlung zu folgen.
Aber eigentlich hast Du ja Recht: ISO ist nunmal ISO und ein spezieller Internetstandard macht hier keinen Sinn. Ich ziehe daher meine Empfehlung zurueck und schliesse mich Deiner Korrektur an.so short
Christoph Zurnieden
-
-
Lieber Christoph,
das Datumsformat reicht völlig in der Form (yyyy.mm.dd), sodass dann per locale die jeweilige Form generiert werden kann (oder gleich ein unix-Zeitstempel). Da bin ich für Vorschläge offen. Aber man sollte die kirche im Dorf lassen...
Zu Deinem "unclosed token" Problem:
Bitte vollstaendige FehlermeldungXML error: not well-formed (invalid token) at line xxx
Bitte genuegend Daten zum Nachvollziehen
Kommt gleich weiter unten!
Bitte die Namen und Versionen aller Beteiligten (hier reichen wohl PHP und XML-Parser)
Also auf meinem Win32-Apache2.0.52 sagt phpinfo():
- php-Version 4.3.10
- XML
- XML Support active
- XML Namespace Support active
- EXPAT Version 1.95.6 - xmlrpc
- core library version xmlrpc-epi v. 0.51
- php extension version 0.51
- author Dan Libby
Hoffentlich war jetzt das von Dir Verlangte auch dabei...
Die GB-XML-Datei (wesentlicher Auszug):
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <!DOCTYPE gaestebuch [ <!ELEMENT gaestebuch (eintrag)+> <!-- definiert das Grundgerüst des Dateiformates --> <!ENTITY und "&"> <!-- "und"-Zeichen (Ampersand) --> <!ENTITY zeilenumbruch " "> <!-- "Zeilenumbruch" Windows-kompatibel --> <!ELEMENT eintrag (autor, nachricht)> <!-- definiert den Aufbau eines GB-Eintrags --> <!ATTLIST eintrag datum CDATA #REQUIRED zeit CDATA #REQUIRED > <!ELEMENT autor (#PCDATA)> <!-- definiert den Aufbau der Daten über den Autor eines Eintrags --> <!ATTLIST autor email CDATA #IMPLIED homepage CDATA #IMPLIED icq CDATA #IMPLIED aim CDATA #IMPLIED yim CDATA #IMPLIED msn CDATA #IMPLIED > <!-- Die Zusatzdaten zum Autor werden in diesen Attributen gespeichert --> <!ELEMENT nachricht (#PCDATA)> <!-- definiert den Aufbau der Daten für die Nachricht --> ]> <gaestebuch> <eintrag datum="28.04.2005" zeit="20:20"> <autor email="" homepage="">Susi</autor> <nachricht>SO&zeilenumbruch;wollt nur nochmal die Caro grüßen!!!&zeilenumbruch;Kommt Philipp&und;Tanja morgen mit?</nachricht> </eintrag> </gaestebuch>Die unclosed Entity befindet sich in der Zeile <nachricht></nachricht> und bezieht sich auf das
&und;. Anscheinend wird beim Parsen die Entity in ihren Wert umgewandelt, sodass nur noch ein&(also das Ampersand) übrigbleibt, was er zurecht bemeckert. Aber wenn der Parse-Vorgang verschachtelt abläuft, warum wandelt er die Entities nicht erst ganz zum Schluss um??? Außerdem bekomme ich nur noch den Reststring nach der letzten Entity geliefert. :-(Das erzeugte Array (bei geändertem Ampersand-Wert auf
%!!) dieser Daten sieht so aus:Array ( [0] => Array ( [name] => EINTRAG [attributes] => Array ( [DATUM] => 28.04.2005 [ZEIT] => 20:20 ) [child] => Array ( [0] => Array ( [name] => AUTOR [attributes] => Array ( [EMAIL] => [HOMEPAGE] => ) [content] => Susi ) [1] => Array ( [name] => NACHRICHT [content] => Tanja morgen mit? ) ) ) )Auf php.net hatte ich mir für diese Umwandlung folgende Klasse "mitgenommen", da ich das selbst noch nicht selbst hinbekomme:
class XMLParser { var $filename; var $xml; var $data; function XMLParser($xml_file) { $this->filename = $xml_file; $this->xml = xml_parser_create(); xml_set_object($this->xml, $this); xml_set_element_handler($this->xml, 'startHandler', 'endHandler'); xml_set_character_data_handler($this->xml, 'dataHandler'); $this->parse($xml_file); } function parse($xml_file) { if(!($fp = fopen($xml_file, 'rb+'))) { die('Cannot open XML data file: '.$xml_file); return false; } $bytes_to_parse = 65536; while ($data = fread($fp, $bytes_to_parse)) { $parse = xml_parse($this->xml, $data, feof($fp)); if (!$parse) { die( sprintf("XML error: %s at line %d", xml_error_string(xml_get_error_code($this->xml)), xml_get_current_line_number($this->xml))); xml_parser_free($this->xml ); } } return true; } function startHandler($parser, $name, $attributes) { $data['name'] = $name; if ($attributes) $data['attributes'] = $attributes; $this->data[] = $data; } function dataHandler($parser, $data) { if($data = trim($data)) { $index = count($this->data) - 1; $this->data[$index]['content'] = $data; } } function endHandler($parser, $name) { if (count($this->data) > 1) { $data = array_pop($this->data); $index = count($this->data) - 1; $this->data[$index]['child'][] = $data; } } } // XML-Daten in ein Array umwandeln $daten = new XMLParser($datendatei); $daten = $daten->data[0];Diese Klasse ist nicht von mir. Ich verstehe sie auch nicht wirklich, da ich in PHP das Objektorientierte noch nicht kann. Aber anscheinend ist sie nicht optimal, denn sie gibt mir die Zeile Nachricht erst nach dem
&und;aus... nachdem ich in der DTD den Wert verändert habe. *grr*Für eine bessere Parser-Klasse bin ich ebenso dankbar, wie für Hinweise, die Denkfehler von mir aufzeigen.
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
das Datumsformat reicht völlig in der Form (yyyy.mm.dd), sodass dann per locale die jeweilige Form generiert werden kann (oder gleich ein unix-Zeitstempel). Da bin ich für Vorschläge offen. Aber man sollte die kirche im Dorf lassen...
Ich glaube Tim hat da Recht: wenn's schon eine ISO gibt und W3C die fuer XML nutzt, dann sollte man das auch tun.
Zu Deinem "unclosed token" Problem:
Bitte vollstaendige Fehlermeldung
XML error: not well-formed (invalid token) at line xxxGibt es da wirklich drei Kreuze statt der Zeilennummer? ;-)
<!ENTITY und "&">
Argh, jetzt seh' ich es erst:
Aber gut: bei _der_ Fehlermeldung! ;-)
Es muss natuerlich heissen:
<!ENTITY und "&#38;">so short
Christoph Zurnieden
-
Lieber Christoph,
abermals vielen Dank für Deine Antwort, die wieder etwas mehr Licht ins Dunkel bringt.
Ich glaube Tim hat da Recht: wenn's schon eine ISO gibt und W3C die fuer XML nutzt, dann sollte man das auch tun.
Diese ISO sagt mir (noch) nix. Heißt das, dass es auf dieser ISO basierend eine (oder mehrere) DTD(s) gibt, die ich statt meiner selbstgestrickten verwenden sollte?
<!ENTITY und "&">
Argh, jetzt seh' ich es erst:
Aber gut: bei _der_ Fehlermeldung! ;-)
Es muss natuerlich heissen:
<!ENTITY und "&#38;">Das verstehe ich jetzt nicht ganz, da mir die Maskierung (offensichtlich handelt es sich hierbei um eine solche) des Ampersand-Zeichens nicht klar ist. Seltsamerweise hat der Validator ein
&in meinem Dokument nicht beanstandet, obwohl diese Entity in meiner inline-DTD nicht definiert war!Mittlerweile habe ich das mit den Entities aufgegeben, setzte intern ein BB-Code-System (selbstgestrickt, User sieht es nicht und kann es offiziell nicht einsetzen) ein und maskiere Ampersands mit
&.Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
Ich glaube Tim hat da Recht: wenn's schon eine ISO gibt und W3C die fuer XML nutzt, dann sollte man das auch tun.
Diese ISO sagt mir (noch) nix. Heißt das, dass es auf dieser ISO basierend eine (oder mehrere) DTD(s) gibt, die ich statt meiner selbstgestrickten verwenden sollte?Nein, eine ISO fuer das Zeitformat, das auch das W3C fuer sein XML-Format verwendet wissen moechte.
<!ENTITY und "&#38;">
Das verstehe ich jetzt nicht ganz, da mir die Maskierung (offensichtlich handelt es sich hierbei um eine solche) des Ampersand-Zeichens nicht klar ist.Wenn Du ein Ampersand haben moechtest musst Du das maskieren. Tust Du das nicht wird es geparsed. Soweit klar? Gut. Ein ENTITY ist jedoch nichts weiter, als ein "dummer" Ersetzungsmechanismus aehnlich eines "define" in C/C++. Erst wird ersetzt, dann geparsed. Vorher hattest Du nach dem parsen ein einsames '&' stehen, das eine Bedeutung hat:"es folgt ein Entity". Da ein Entity mit einem ';' beendet werden muss gab es die etwas zu allgemeine Fehlermeldung "unclosed token". Jetzt steht da ein vollstaendiges Entity nach dem Parsen '&'.
Nae, das war nicht sonderlich gut erklaert, kann das irgendjemand anders evt besser?
Seltsamerweise hat der Validator ein
&in meinem Dokument nicht beanstandet, obwohl diese Entity in meiner inline-DTD nicht definiert war!Einige sind vordefiniert: "lt", "gt", "apos", "quot" und "amp".
Ja, steht des denn etwa nicht in SELFHTML? ;-)Mittlerweile habe ich das mit den Entities aufgegeben, setzte intern ein BB-Code-System (selbstgestrickt, User sieht es nicht und kann es offiziell nicht einsetzen) ein
Nein, ich wuerde die Idee mit den Entities fortfuehren. Selbstgestrickt heisst hier das Rad neu zu erfinden.
Benoetigst Du ueberhaupt eigene?und maskiere Ampersands mit
&.Es gibt in PHP einiges an Werkzeug, das Dir solcherart Maskierungen abnimmt. Nutze sie.
so short
Christoph Zurnieden
-
Lieber Christoph,
die Sache mit den Entities muss ich nochmal aufgreifen!
Mittlerweile habe ich das mit den Entities aufgegeben, setzte intern ein BB-Code-System (selbstgestrickt, User sieht es nicht und kann es offiziell nicht einsetzen) ein
Nein, ich wuerde die Idee mit den Entities fortfuehren. Selbstgestrickt heisst hier das Rad neu zu erfinden.
Benoetigst Du ueberhaupt eigene?Also Zeilenumbrüche werden in XML sozusagen beim Parsen ignoriert. Ich möchte aber im String-Output des Parsers (auch wenn dieser String in einem Array sitzt) den Zeilenumbruch haben! Daher gedachte ich zuerst, eine Entity
&zeilenumbruch;zu definieren. Aber das Ergebnis war nicht das gewünschte. Ich habe das mit dem Maskieren noch nicht wirklich begriffen!Mein Versuch war folgender:
<!ENTITY zeilenumbruch " ">
Im String finde ich aber keinen Zeilenumbruch (ASCII-Zeichen 10 oder/und 13)... Weißt Du da Rat?Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
Mein Versuch war folgender:
<!ENTITY zeilenumbruch " ">
Im String finde ich aber keinen Zeilenumbruch (ASCII-Zeichen 10 oder/und 13)... Weißt Du da Rat?Dann ueberlege mal, warum es auch bei HTML kein solches Entity gibt, sondern ein komplettes Element mit der Aufgabe das Zeilenende zu markieren beauftragt wurde ;-)
Nein, der Grund ist genau derselbe, wie beim Ampersand: das wird zuerst aufgeloest und kommt deshalb nicht mehr in den Baum.so short
Christoph Zurnieden
-
Lieber Christoph,
Dann ueberlege mal, warum es auch bei HTML kein solches Entity gibt, sondern ein komplettes Element mit der Aufgabe das Zeilenende zu markieren beauftragt wurde ;-)
Nein, der Grund ist genau derselbe, wie beim Ampersand: das wird zuerst aufgeloest und kommt deshalb nicht mehr in den Baum.damit bestätigst Du mich in meinem BB-Code-Vorgehen, in welchem ich den Zeilenumbruch realisiere. Alternativ könnte ich auch ein Element "br" definieren, um das XHTML-Tag
<br />zur Verfügung zu haben, aber das lohnt den Aufwand nicht (da es dann im Array wiederum herumgeistert, usw.).Vielen Dank für die genauere Erklärung mit den Entities!
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
-
-
-
-
-
-
Hallo Felix.
Das Plus-Zeichen ist schnell durch einen Asterix ersetzt. :-)
[Wikipedia: Asterix] oder [Wikipedia: Asterisk]?
Einen schönen Mittwoch noch.
Gruß, Ashura
-
-
Lieber Christoph,
einen Punkt hatte ich bisher übersehen:
[...] denn wenn da Unsinn drin steht oder Spam oder anderes soll das natuerlich raus.
Daher wäre noch ein Attribut nötig, das eine Freigabe (oder etwas in der Art) enthält, ob der Eintrag nun öffentlich angezeigt werden soll, oder nicht. Mein Vorschlag wäre:
<!ATTLIST eintrag
datum CDATA #REQUIRED
zeit CDATA #REQUIREDmoderator (public|private) #REQUIRED
>
Das mit den Instant Messengers... Du meintest:
[...], aber ...
icq CDATA #IMPLIED
aim CDATA #IMPLIED
yim CDATA #IMPLIED
msn CDATA #IMPLIED
... das ist eine unnoetige Begrenzung der Variabilitaet.
Dafuer sollte lieber ein eigenes unspezifisches Element angeboten werden, z.B.
<!ELEMENT autor (aname,(aadress)*)>
<!ELEMENT aname (#PCDATA )>
<!ELEMENT aadress EMPTY>
<!ATTLIST aadress
protocol CDATA #REQUIRED
ref CDATA #REQUIRED>Ich denke, die Protokolle für Email und Homepage sind irgendwie fest etabliert, da wird sich wohl kaum etwas ändern, oder? Also warum diese nicht als Attribute für "Autor" realisieren? Die anderen "Adressen" für die diversen Instant Messengers könnte man als mehrfach mögliches leeres Element "im" realisieren, welches die Attribute "protocol" und "ref" enthält, also genau so, wie Du in obigem Beispiel unter "ELEMENT aadress" vorgeschlagen hast. Damit sähe die DTD so aus:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <!DOCTYPE gaestebuch [ <!ELEMENT gaestebuch (eintrag)*> <!-- definiert das Grundgerüst des Dateiformates --> <!ELEMENT eintrag (autor, nachricht, (im)*)> <!-- definiert den Aufbau eines GB-Eintrags --> <!ATTLIST eintrag datum CDATA #REQUIRED zeit CDATA #REQUIRED > <!ELEMENT autor (#PCDATA)> <!-- definiert den Aufbau der Daten über den Autor eines Eintrags --> <!ATTLIST autor email CDATA #IMPLIED homepage CDATA #IMPLIED > <!-- definiert Email-Adresse und Homepage des Autors (optional) --> <!ELEMENT im EMPTY> <!-- definiert ein Element, das Kontakt-Daten für Instant-Messengers enthält --> <!ATTLIST im protocol CDATA #REQUIRED ref CDATA #REQUIRED > <!-- Die notwendigen Angaben zum Instant Messaging Dienst werden hier gespeichert --> <!ELEMENT nachricht (#PCDATA)> <!-- definiert den Aufbau der Daten für die Nachricht --> ]>Käme das in etwa Deinem Vorschlag gleich?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
einen Punkt hatte ich bisher übersehen:
[...] denn wenn da Unsinn drin steht oder Spam oder anderes soll das natuerlich raus.
Daher wäre noch ein Attribut nötig, das eine Freigabe (oder etwas in der Art) enthält, ob der Eintrag nun öffentlich angezeigt werden soll, oder nicht.Warum?
Wenn etwas raus soll, ist es das Beste es auch tatsaechlich raus zu nehmen.
Das erfordert sechs Schritte:- Identifizieren des Knotens (haendisch/automatisch)
- Locking der DB
- Einlesen des Baumes
- Entfernen des Knotens aus 1)
- Ueberschreiben der alten DB mit dem neuem Baum
- Freigabe der DB
Dein Vorschlag beschraenkt sich zwar nur auf den Punkt 1) macht aber fast genau die gleiche Arbeit, nur Punkt 4) faellt weg. (und Punkt 5) wenn Du das Attributersetzen "von Hand" machst, aber mit dem Baum zu arbeiten sollte eigentlich einfacher sein)
Die Identifizierung koennte eine individuelle Eintrags-ID ereichtern (vor allem, wenn die Dinger schon in's Archiv gerutscht sind), aber das wolltest Du ja nicht.
Wenn Du aber etwas zusaetzliches haben moechtest koenntest Du (Fuzzy-)Checksums erstellen und eintragen, das erleichtert das automatische Auffinden von Doppelpostings und kann auch zum Teil auch Spam automatisch erkennen.
Dies waere aber auch eher mit einem ganzem Element zu installieren, nicht mit einem Attribut alleine:<!ELEMENT hash EMPTY>
<!ATTLIST hash
type CDATA #REQUIRED
chksum CDATA #REQUIRED>Details dann wieder in's XML-Schema.
Ich denke, die Protokolle für Email und Homepage sind irgendwie fest etabliert, da wird sich wohl kaum etwas ändern, oder?
Warum moechtest Du so ein Durcheinander veranstalten?
Ein allgemeines Element ist genau richtig dafuer, warum moechtest Du Attribute, die zudem noch freiwillig sind und noch ein allgemeines Element _zusaetzlich_?
KISS: "Keep it simple, stupid!" ;-)so short
Christoph Zurnieden
-
Lieber Christoph,
Daher wäre noch ein Attribut nötig, das eine Freigabe (oder etwas in der Art) enthält, ob der Eintrag nun öffentlich angezeigt werden soll, oder nicht.
Warum?Nunja, ich habe schon GBs gesehen, in denen Einträge erst nach händischem Überprüfen zur Anzeige freigegeben werden. Bis dahin schlummern sie unsichtbar vor sich hin. Eine "Moderator"-Funktion wäre mit solch einem Attribut leicht realisiert...
Wenn etwas raus soll, ist es das Beste es auch tatsaechlich raus zu nehmen.
Völlig klar! Aber bis das feststeht... :-)
Ich denke, die Protokolle für Email und Homepage sind irgendwie fest etabliert, da wird sich wohl kaum etwas ändern, oder?
Warum moechtest Du so ein Durcheinander veranstalten?
Ein allgemeines Element ist genau richtig dafuer, warum moechtest Du Attribute, die zudem noch freiwillig sind und noch ein allgemeines Element _zusaetzlich_?
KISS: "Keep it simple, stupid!" ;-)Das klingt allerdins sehr überzeugend... Werde mal darüber nachdenken. Für unsere Schulhomepage werde ich es mal dabei belassen, aber für ein "offizielles" GB-Script könnte ich mir vorstellen, solches noch umzusetzen.
Jedenfalls war dieser ganze Dialog mit Dir und den anderen Forumsteilnehmern wie immer wiedermal eine Bereicherung für mich!
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
Hi,
Daher wäre noch ein Attribut nötig, das eine Freigabe (oder etwas in der Art) enthält, ob der Eintrag nun öffentlich angezeigt werden soll, oder nicht.
Warum?
Nunja, ich habe schon GBs gesehen, in denen Einträge erst nach händischem Überprüfen zur Anzeige freigegeben werden.Das ist kein Gaestebuch mehr, das hat zumindest nicht mehr viel damit zu tun, das sind eher "Leserbriefe". Dafuer wuerde ich ein Redaktionssytem empfehlen mit Formular zwecks Fremdeingabe.
Aber ich habe eine guten Grund fuer sowas glatt verschlampt: es kann moeglich sein, das eine Beweissicherungspflicht oder auch nur ein -willen besteht (wie in diesem Forum hier). Dafuer koennte so eine Markierung natuerlich hilfreich sein.
Dann aber vollstaending und flexibel, nicht als schaebiges Attribut.<!ELEMENT publication(#PCDATA)>
<!ATTLIST publication
publish (yes|no) #REQUIREDDa das Element fuellbar ist, kann da bequem ein Kommentar rein:
<publication publish="no">
Hier wird behauptet, das die Quirbelfoops nach der dritten Benutzung zu explodieren pflegen. Bitte nicht veroeffentlichen bis ich meine Aktien der Quirbel-AG verkauft habe, danke.
</publication>Wenn etwas raus soll, ist es das Beste es auch tatsaechlich raus zu nehmen.
Völlig klar! Aber bis das feststeht... :-)Wie gesagt: das ist ein anderes Thema.
Jedenfalls war dieser ganze Dialog mit Dir und den anderen Forumsteilnehmern wie immer wiedermal eine Bereicherung für mich!
Deine Art zu sagen "Is' gut jezz!"? ;-)
so short
Christoph Zurnieden
-
Lieber Christoph,
Das ist kein Gaestebuch mehr, das hat zumindest nicht mehr viel damit zu tun, das sind eher "Leserbriefe". Dafuer wuerde ich ein Redaktionssytem empfehlen mit Formular zwecks Fremdeingabe.
Interessanter Gedanke! Aber wie Du gleich selbst schreibst, vielleicht doch auch in einem GB nützlich:
Aber ich habe eine guten Grund fuer sowas glatt verschlampt: es kann moeglich sein, das eine Beweissicherungspflicht oder auch nur ein -willen besteht (wie in diesem Forum hier). Dafuer koennte so eine Markierung natuerlich hilfreich sein.
Dann aber vollstaending und flexibel, nicht als schaebiges Attribut.
Da das Element fuellbar ist, kann da bequem ein Kommentar rein:
<publication publish="no">
Hier wird behauptet, das die Quirbelfoops nach der dritten Benutzung zu explodieren pflegen. Bitte nicht veroeffentlichen bis ich meine Aktien der Quirbel-AG verkauft habe, danke.
</publication>Das klingt sehr sinnvoll. Diese Quirbelfoops würden mich jetzt echt interessieren, weil das klingt irgendwie lecker! *gg*
Jedenfalls war dieser ganze Dialog mit Dir und den anderen Forumsteilnehmern wie immer wiedermal eine Bereicherung für mich!
Deine Art zu sagen "Is' gut jezz!"? ;-)Nee, garnicht! Aber Du schreibtest in einem vorhergehenden Posting "Naja, viel faellt mir dazu aber nicht mehr ein.", daher dachte ich, Du würdest Dich so langsam ausklinken. Wahr wohl ein Irrtum. Dann habe ich eben mehr von Dir. ;-)
Liebe Grüße aus Ellwangen,
Felix Riesterer.
-
-
-
-