Hallo Zusammen
In einem kleinen Projekten das ich kürzlich angefangen habe (soll etwas
zwischen GUI Toolkit und Display Server werden), brauchte ich eine
Markup Language. Ich mag XML und HTML eigentlich, aber es gibt auch
Aspekte, die ich etwas nervig finde. Darum schreibe ich gerade einen
Parser für eine eigene Variation davon. Ich nenne das Format mal ML666
(anfangs habe ich versucht ein 3 oder 4 Buchstaben Akronym das auf ML
endet zu finden, aber die sind alle in Verwendung, irgendwann hab ich
aufgegeben und einfach eine Nummer angehängt).
Das ganze ist XML sehr ähnlich, daher hier mal ein Vergleich.
ml666:
Folgendes mach ich anders:
* Keine root node
* Keine HTML entities, statdessen alles utf8, und man kann mit \
folgende 5 Zeichen (und nur diese) escapen: < ">\
* Keine Limitationen wo man welche Zeichen verwenden kann, ein > im tag
name? Kein Problem, einfach escapen!
* Text nodes werden explizit mit <!>text</!>gekennzeichnet. Die erste
und letzte Leerzeile wird jeweils ignoriert. Damit ist immer klar, wo
Abstände nur der Formatierung dienen, und wo diese zum Text / Inhalt
gehören.
* Kommentare mit <!-->text</!--> statt mit <!-- text -->. Text und
Kommentare sehen damit mehr wie normale Tags aus.
Ein kleines Konvertier Skript (soweit möglich) hab ich auch (siehe
Anhang).
Was haltet ihr von dem Format?
JSON & YAML sind toll für Daten. Aber als Markup Language zum
beschreiben einer GUI sind sie komplett ungeeignet. Dort hat man meist
einen UI Tree, jede Node kann Inhalt / Child nodes haben, hat aber
selbst auch eigenschaften. Das kann man mit JSON abbilden, aber dann
braucht man pro Node 2 Objekte und 1 Array, das wird beim verschachteln
schnell unübersichtlich, und verursacht viel mehr bloat als eine
dedizierte Syntax für diesen Anwendungsfall.
DPA schrieb:> Was haltet ihr von dem Format?
Abstand. Da hat wohl jemand zu viel Zeit gehabt (arbeitslos? Student?
Lebenskünstler? Sohn? Erbe?). Im echten Leben möchte man Standards
benutzen, damit später auch noch mal jemand anderes daran weiterarbeiten
kann, und man verwendet seine Zeit, um echte Probleme zu lösen, die auch
bezahlt werden.
Und das Problem, GUIs per XML zu beschreiben, wurde ja auch schon
mehrfach erfolgreich gelöst: unter anderem einmal von Microsoft und
einmal von QT (das ist das, was mir auf die Schnelle einfällt).
fchk
Man kann sich schon seine eigene Markuplanguage generieren. Aber wozu
soll das gut sein und wozu soviel Aufwand betreiben? Es gibt doch
mittlerweile genug Auszeichnungssprachen, da wird doch was dabei sein,
womit Du Deine Daten abbilden können solltest.
Ich kann in Deinem Ansatz keinen wirklichen Mehrwert gegenüber dem
Vorhandenen erkennen. Wozu braucht es noch den <!>/</!> Tag. Der ist in
meinen Augen so überflüssig wie ein Kropf.
Hauptnachteil eine eigenen Auszeichnungsmethode ist, das sie mehr oder
weniger probitär ist, d.h. es wird keine Frameworks, außer das von Dir
geschriebene, geben welche diese Eigencreation unterstützen. Damit ist
DEin Code praktisch nicht wartbar. Wenn das natürlich Deine Absicht ist,
kannst Du das so machen, mir wäre es zuviel Aufwand.
Zeno schrieb:> Es gibt doch> mittlerweile genug Auszeichnungssprachen, da wird doch was dabei sein,> womit Du Deine Daten abbilden können solltest.
Bekannt sind HTML, XML, SGML. Es gibt viele andere, aber selber was
machen geht schneller, als nach etwas existierendem zu suchen / lohnt
sich nicht wirklich.
Zeno schrieb:> Wozu braucht es noch den <!>/</!> Tag. Der ist in> meinen Augen so überflüssig wie ein Kropf.
Den braucht man, um das ganze ansehnlich formatieren zu können. In HTML
hatte ich das Problem oft. In folgendem HTML Beispiel gibt es 3 Text
Nodes:
1
<div>
2
<img/>
3
<img/>
4
</div>
Aber will man den Abstand zwischen den <img/> überhaupt? vermutlich
nicht. Aber ohne die Abstände wird es unlesbar
<div><img/><img/></div>.
In ml666, wollte man die Abstände tatsächlich, würde es so aussehen:
1
<div>
2
<!>
3
4
5
</!>
6
<img/>
7
<!>
8
9
10
</!>
11
<img/>
12
<!>
13
14
</!>
15
</div>
Und genau das ist der Vorteil. Text wird explizit. Keine Verrenkungen
mehr wegen ungewollter Abstände. Ok, ich könnte in XML auch einfach nur
Text beachten, der in einem <text></text> tag oder so ist, aber
das ist dann in einer anderen Ebene geregelt.
Zeno schrieb:> Hauptnachteil eine eigenen Auszeichnungsmethode ist, das sie mehr oder> weniger probitär ist, d.h. es wird keine Frameworks, außer das von Dir> geschriebene, geben welche diese Eigencreation unterstützen.
Das Format ist so derart simpel, das sollte kaum ein Problem sein. Ich
würde sogar behaupten, ml666 ist einfacher zu nutzen, selbst ohne
spezielle libs & Frameworks, als z.B. XML mit. Nur schon das viel
einfachere Escaping, und dass man bei Tags und Attributen wirklich alles
kodieren kann, vereinfacht da vieles. Ich kann einen simplen aber
vollständigen Serializer inklusive Indentierung & escaping in 18 Zeilen
JS schreiben:
Und wie prüftst du ob dein input synthaktisch korrekt ist? Brauchste
alles nicht, schon klar. Da gehts doch schon los, das liefert xml alles
von Haus aus mit. Das ist selbergebastelter Müll, schon x-fach gesehen.
Die Fehler die du dir damit einhandelst hast du gar nicht auf dem Radar
weil du ein Greenhorn bist. YAML ist übrigens der gleiches Scheissdreck,
eher noch schlimmer, die Parser dafür sind alle defekt, selbst das ach
so einfache JSON macht Ärger, weil da jeder was anderes darunter
versteht und jeder Parser leicht anders interpretiert. Gibt ne nette
Seite dazu im Netz wie kaputt auf den ersten Blick der simple Kram
wirklich ist. XML wurde nicht ohne Grund so entworfen wie es ist.
Frank K. schrieb:> DPA schrieb:>>> Was haltet ihr von dem Format?>> Abstand. Da hat wohl jemand zu viel Zeit gehabt (arbeitslos? Student?> Lebenskünstler? Sohn? Erbe?). Im echten Leben möchte man Standards> benutzen, damit später auch noch mal jemand anderes daran weiterarbeiten> kann, und man verwendet seine Zeit, um echte Probleme zu lösen, die auch> bezahlt werden.
Vor allem will ich doch nicht auf den ganzen Komfort und die Funktionen,
die die ganzen existierenden (und ausführlich getesteten) XML-Parser
haben, verzichten und mit stattdessen einen eigenen Parser schreiben,
nur weil mein Format in ein paar wenigen Details davon abweicht.
DPA schrieb:> Bekannt sind HTML, XML, SGML. Es gibt viele andere, aber selber was> machen geht schneller, als nach etwas existierendem zu suchen / lohnt> sich nicht wirklich.
Genau umgekehrt: Was existierendes einfach zu nehmen, geht schneller,
als sich den Umstand zu machen, das alles selbst zu implementieren.
> Zeno schrieb:>> Wozu braucht es noch den <!>/</!> Tag. Der ist in>> meinen Augen so überflüssig wie ein Kropf.>> Den braucht man, um das ganze ansehnlich formatieren zu können. In HTML> hatte ich das Problem oft. In folgendem HTML Beispiel gibt es 3 Text> Nodes:<div>> <img/>> <img/>> </div>> Aber will man den Abstand zwischen den <img/> überhaupt?
Wenn man den will, nimmt man eben eine CData-Sektion.
> In ml666, wollte man die Abstände tatsächlich, würde es so> aussehen:
Was ist, wenn du das Newline haben willst, aber die Leerzeichen nicht?
> Das Format ist so derart simpel, das sollte kaum ein Problem sein. Ich> würde sogar behaupten, ml666 ist einfacher zu nutzen, selbst ohne> spezielle libs & Frameworks, als z.B. XML mit.
Mit einem DOM-Parser kann ich ein XML einlesen, dabei gegen ein Schema
validieren und bekomme das Ergebnis als Objekthierarchie fertig
geliefert. Die kann ich dann bearbeiten und am Ende daraus wieder ein
XML machen. Kann dein Parser das auch?
Riesenschwengel schrieb:> selbst das ach> so einfache JSON macht Ärger, weil da jeder was anderes darunter> versteht und jeder Parser leicht anders interpretiert. Gibt ne nette> Seite dazu im Netz wie kaputt auf den ersten Blick der simple Kram> wirklich ist.
Da isses:
Parsing JSON is a Minefield
http://seriot.ch/projects/parsing_json.html
Zu YAML gibts auch genug, sucht selber nach den rants.
Die Spec zu dem "einfachen" Format ist länger als die von XML!
Whitespace Teil der Synthax,... von Amateuren entworfen.
Rolf M. schrieb:>> In ml666, wollte man die Abstände tatsächlich, würde es so>> aussehen:>> Was ist, wenn du das Newline haben willst, aber die Leerzeichen nicht?
Überhaupt kein Problem. Ist im Beispiel oben ja sogar mit dabei. Um das
nochmal klarer zu machen, bei:
1
<!>
2
3
</!>
Entspricht das dem cstring "\n". Also aus "\n\n\n " wird "\n". Nur das
erste, und die letzte Zeile, sofern nur abstände, geht weg. Die
restlichen abstände und newlines bleiben gleich. So kann jede
Kombination von Abständen und Newlines problemlos repräsentiert werden.
Rolf M. schrieb:> Mit einem DOM-Parser kann ich ein XML einlesen, dabei gegen ein Schema> validieren und bekomme das Ergebnis als Objekthierarchie fertig> geliefert. Die kann ich dann bearbeiten und am Ende daraus wieder ein> XML machen. Kann dein Parser das auch?
Sowas könnte ich auch einbauen. Aber momentan brauche ich es für meinen
Anwendungsfall nicht. Ich werde darin keine Daten für eine vordefinierte
Datenstruktur speichern, und meine Tags werden auch dynamisch sein. Ich
hab da vor, was ähnliches wie beim html shadow dom zu machen, und
definiere die Tag Namen dann anhand der Dateinamen der Layouts in den
.ml666.
Die meisten Tag Namen werden dann quasi Imports. Dann hätte ich z.B.
<mycoolplayer:video src="test.mpf" /> in einer Datei, und die lädt dann
mycoolplayer/video.ml666, wo dann z.B. die video player controls usw.
drin sind, usw. Wobei, vielleicht lass ich das Laden der Elemente &
Controller auch manuell, hab ich noch nicht entschieden. Auf jeden Fall
habe ich keine fixen Strukturen im sinne eines Schemas, oder zumindest
keine, die man manuell definieren müsste.
Riesenschwengel schrieb:> Da isses:> Parsing JSON is a Minefield> http://seriot.ch/projects/parsing_json.html
Die paar Sachen sehe ich eigentlich nicht als Problem für JSON an.
Das mit den Parsern ist hingegen interessant. Schon fast ein Argument,
nicht etwas bestehendes zu nehmen.
> Zu YAML gibts auch genug, sucht selber nach den rants.
Ja, YAML ist scheisse.
Ich fasse mal zusammen: auf deine Frage: Eigene *ML Variation statt
XML/HTML, was haltet ihr davon?
Antwortet das oft zutiefst zerstrittene Mikrocontroller Forum, unisono
es ist keine gute Idee bleib bei ein existenten Standard!
Danach versucht du die technischen Argumente zu widerlegen, sagst aber
nichts zu den zwei wichtigen Fragen, die einen Ingenieur, wirklich
wissen will.
1.) was stimmt mit den anderen ML Sprachen konkrete nicht, das deine
Sprache besser machen will?
2.) warum sollte man deine proprietäre Lösung einer 80 % Lösung mit
offenen Standards vorziehen.
Gerade die zweite Frage ist entscheidend. Denn bei einem offenen
Standard gibt es Tools, Frameworks und externe Experten, die ich im
Zweifel einkaufen kann, um meine Probleme zu lösen. Dass du einen Parser
für deine ML in 18 Zeilen schreiben kannst (oder 1, wenn du Perl nimmst
;) ) ist zwar schön zu wissen, aber was mich mehr interessiert sind,
gibt es eine öffentliche vollständige Spezifikation, wie robust ist der
Parser gegen kaputten Input, welche Testcases hat deine ML.
Bis jetzt bist du der einzige zu sein, der an dein Projekt glaubt. Das
muss nicht heißen das dein Projekt falsch ist, aber die
Wahrscheinlichkeit ist hoch diese Idee eine Sackgasse ist, denn die Welt
scheint noch nicht überzeugt eine weitere ML zu brauchen.
DPA schrieb:> Das Format ist so derart simpel, das sollte kaum ein Problem sein. Ich> würde sogar behaupten, ml666 ist einfacher zu nutzen, selbst ohne> spezielle libs & Frameworks, als z.B. XML mit.
Für so etwas einen eigenen Parser schreiben? Sag mal gehts noch. Da
greif ich dann doch lieber auf was was Vorhandenes zurück.
In fast jeder Programmiersprache, die ich kenne, gibt es Parser für XML
und die sind meist auch recht komfortabel, was ihre Anwendung betrifft.
Dein ! Tag ist und bleibt unnötig. Einfacher Text wird in
Markuplanguages einfach zwischen den Start- und den Endtag geschrieben -
fertig. Das man da Zeichen die Bestandteil der Sprache selbst sind,
escapen muß ist nun mal so.
Mit diesem Sonderweg machst Du Dein Programm für andere praktisch
unwartbar. Es wird eine (Deine) Einzelfalllösung bleiben. Wenn das so
gewünscht ist, dann mach es einfach, es wird Dich keiner daran hindern.
imonbln schrieb:> Antwortet das oft zutiefst zerstrittene Mikrocontroller Forum, unisono> es ist keine gute Idee bleib bei ein existenten Standard!
Aber das ist doch langweilig... Ausserdem bin ich da schon zu tief drin.
Naja, vielleicht lasse ich am ende auch einfach mehrere Formate zu (aber
um die Limitationen werde ich keine Workarounds machen, wenn was in XML
nicht geht, müssen die User dann halt was anderes nehmen. Wobei, der
bekommt sowieso zugriff auf das die GUI OM API, können also auch selbst
einen Parser aussuchen oder schreiben.).
imonbln schrieb:> 1.) was stimmt mit den anderen ML Sprachen konkrete nicht, das deine> Sprache besser machen will?
Bei XML & HTML:
1) Entities / escaping sind unnötig komplex.
2) Wenn man die tags mit Abständen oder Tabs schön formatiert, sind die
teil des Inhalts eines Tags. Insbesondere in HTML hat das schon viele
zur Verzweiflung gebracht, und zu vielen Hacks geführt:
https://www.google.ch/search?q=html+get+rid+of+space+inline+block
3) Keine Einschränkungen welche Zeichen man wo hinsetzen kann. In XML
und HTML, kann man diverse Zeichen nicht in Tag Namen & Attributnamen
haben. Wenn man mal eins bräuchte, kann man nur hoffen, dass der
serializer wenigstens einen Fehler wirft. In ml666 Escape man es
stattdessen halt einfach.
> 2.) warum sollte man deine proprietäre Lösung einer 80 % Lösung mit> offenen Standards vorziehen.
Naja, vielleicht Standardisier ich das ja auch mal noch. Etwas formale
Doku hatte ich sowieso noch vor umzusetzen. Aber warum man sie vorziehen
sollte, da gibt es keinen echten Grund. HTML hat sich trotz der Existenz
von XML etabliert. YAML obwohl es schon JSON gab. Sowas ist eher eine
Sache von worauf man gerade lust hat. Eigentlich müssen nur genug damit
Leute zutun bekommen & davon hören, dann kommen die Fans schon
irgendwann.
imonbln schrieb:> aber was mich mehr interessiert sind, gibt es eine öffentliche vollständige
Spezifikation,
Muss ich noch machen.
> wie robust ist der Parser gegen kaputten Input,
Ich hab einen in C, aber der ist noch nicht ganz fertig. Es wird ein
Tokenizer und ein Parser geben. Der Tokenizer wird sehr solide sein. Es
gibt ein paar wenige fälle, die nicht erlaubt sind (z.B. leere Tags,
nicht escapte < innerhalb von text, usw.). Bei denen erkennt schon der
Tokenizer den Fehler. Zusammensetzen langer Token, der Aufbau des Trees,
und der vergleich von Start / End tag Namen, übernimmt dann der Parser.
Vielleicht prüfe ich später auch noch irgendwo, ob es valides UTF-8 ist.
Der Parser wird ein Streaming top-down Parser. Ich rechne damit, dass es
am Ende sehr solide wird. Programmfehler / crashes werde ich keine
einbauen ;)
> welche Testcases hat deine ML.
Das ist auch noch ausstehend. Momentan teste ich momentan hauptsächlich
einige Sachen beim Tokenizer. Sind einfach einige Datei mit input, und
einige mit erwartetem output. Ich teste unter anderem das Escaping,
token die grösser sind als der Ringbuffer meines Tokenizers (da habe ich
1 page, 2mal gemappt), und einige Edgecases, z.B. was wenn ich 4097
Abstände vor dem text ende tag habe, kann ich nicht einfach die Abstände
ausgeben wenn der Ringbuffer voll ist, sondern muss mir merken, wie
viele da waren, usw.
Momentan ist das alles noch in der Entwicklung. Vielleicht ändere ich
auch noch was an der Syntax. Eigentlich könnte ich auch was kürzeres als
<!>text</!> für Text nehmen. Vielleicht einfach nur >text< ? Und
kommentare könnte ich eigentlich auch /**/ // # statt <!--> nehmen...
Muss ich mir noch überlegen.
Zeno schrieb:> Dein ! Tag ist und bleibt unnötig.
Für mich löst der ein echtes Problem, das ich sonst hätte.
Ich verstehe den aggressiven und teilweise hochnäsigen Ton in diesem
Thread nicht. Habt ihr eure Frau nicht im Griff, so daß ihr euch hier
behaupten müßt? Habt ihr überhaupt eine Frau?
Ansonsten:
Ich wollte mal eine kleine Serialisierung für ein Projekt schreiben,
weil ich Objekte in Dateien speichern wollte und ich nichts fand was
meinen Wünschen entsprach: JSON habe ich probiert, konnte aber nicht mit
zirkulären Strukturen umgehen, die native Javaserialisierung hatte das
Problem das in jeder Klasse ein Interface und ich glaube noch eine
Variable ergänzt werden mußten und ich das evt. für fremde
Bibliotheksklassen nicht wollte, und XML habe ich mir danach schon aus
verschiedenen Gründen nicht mehr angesehen.
Und einige Extrawünsche hat keine dieser Lösungen unterstützt.
Und ja, der Arbeitsaufwand dafür ist ins Unermeßliche explodiert, weil
ich auch am Anfang nicht alles bedacht habe was es zu bedenken gäbe und
ich den Aufwand gnadenlos unterschätzt habe.
Aber dafür ist da mittlerweile eine Lösung entstanden die, so denke ich
jedenfalls, durchaus ein wenig Potential hat und irgendwann mal in ein
eigenes Projekt überführt wird. Und das wichtigste: mit der ICH
zufrieden bin. Daß es "nur" ein Hobbyprojekt ist und Geld für
Entwicklung ja ach so knapp ist, ist keine Entschuldigung für die
Shitware, die wir heute oft haben (vor allem wenn sie von einer
deutschen Firma kommt).
Sorry Leute, wenn ihr für jedes Problem eine fertig vorgekaute Lösung
braucht, dann kann es nicht so wild sein. Was würdet ihr eigentlich tun
wenn ihr sowas wie XML bräuchtet, aber es noch niemand gebaut hätte?
Wartet ihr dann bis jemand es für euch macht?
@DPA:
Ohne deine Anforderungen und deine Lösung jetzt genauer zu kennen: Ich
würde an deiner Stelle deinen Parser erstmal selber ordentlich in deinem
Projekt anwenden und schauen, daß der sich bewährt.
Bei meinem Serialisierer sind mir in der laufenden Anwendung dauernd
Probleme begegnet, an die ich vorher nie gedacht hätte und teilweise
auch gar nicht geahnt habe daß das so passieren kann. Und das waren
alles keine Sachen, die z.B. mit einem Unittest zu erschlagen gewesen
wären.
Ich habe das Gesamtkonzept von meinem Serialisierer bestimmt drei oder
viermal komplett über den Haufen geworfen und neu aufgesetzt, um
sauberen Code und eine saubere Problemlösung zu bekommen (von anfangs
drei Klassen bis heute zu, keine Ahnung, bestimmt 20-30 Klassen und
mehreren tausend Codezeilen). Es ist gut möglich, daß es dir ähnlich
gehen wird.
Aber wenn es dein Problem löst, ja warum nicht? Wenn du dein Problem
nicht löst, macht es ja sonst keiner.
DPA schrieb:> * Keine Limitationen wo man welche Zeichen verwenden kann,> ein > im tag name? Kein Problem, einfach escapen!
Was ist mit einem Newline? Escapen kann/muß mans nicht, also darf es
einfach so im Tag-Namen vorkommen? Was ist mit Tabs?
Ausrufzeichen am Anfang von Tag-Namen erlaubt? !--Hallo auch ein
erlaubter Tag-Name?
DPA schrieb:> * Keine HTML entities, statdessen alles utf8, und man kann #> mit \ folgende 5 Zeichen (und nur diese) escapen: < ">\
Wo bzw. wann genau muß man escapen, wann (darf man) nicht?
DPA schrieb:> * Text nodes werden explizit mit <!>text</!>gekennzeichnet.> Die erste und letzte Leerzeile wird jeweils ignoriert. Damit> ist immer klar, wo Abstände nur der Formatierung dienen, und> wo diese zum Text / Inhalt gehören.
Also gehören die Einrückungen in Deinem Bsp. zum Inhalt?
DPA schrieb:> * Keine root node
Ist die in XML wirklich zwingend vorgeschrieben? Bin mir da jetzt nicht
sicher, aber ich denke nicht, wenn mehrere Dokumente in einer Datei sind
geht das doch. Daß ein Dokument, daß man in einen Baum parsen will eine
Wurzel braucht ist dagegen klar, wenn das Wurzelelement niemals
Attribute haben kann, braucht mans natürlich nicht explizit, aber will
man das wirklich?
DPA schrieb:> Ich rechne damit, dass es> am Ende sehr solide wird. Programmfehler / crashes werde ich keine> einbauen ;)
Bei einem in C geschriebenen Parser für eine selbst ausgedachte
Markup-Sprache ist eine solche Aussage sehr gewagt.
> Zeno schrieb:>> Dein ! Tag ist und bleibt unnötig.>> Für mich löst der ein echtes Problem, das ich sonst hätte.
Manchmal ist es besser, sich mit einem Problemchen anzufreunden, als
massiven Aufwand zu treiben und nebenbei hundert neue Probleme
einzuführen.
Für ein Hobbyprojekt kann man sowas natürlich machen - warum nicht? Was
Spaß macht, ist erlaubt. Und man kann sicher eine Menge lernen.
Wäre das ein kommerzielles oder Open-Source-Projekt, würde ich
allerdings einen großen Bogen darum machen. „Programmierer mag die
spitzen Klammern bei XML nicht und erfindet eigene Markupsprache“ ist so
eine typische Geschichte von https://thedailywtf.com. Sowas fasst kein
anderer Entwickler mehr freiwillig an. Überleg dir einfach, sollen auch
andere Menschen mal freiwillig an dem Projekt weiterarbeiten? Wenn ja,
beherzige den Rat der Foristen hier im Thread.
mIstA schrieb:> DPA schrieb:>> * Keine Limitationen wo man welche Zeichen verwenden kann,>> ein > im tag name? Kein Problem, einfach escapen!>> Was ist mit einem Newline? Escapen kann/muß mans nicht, also darf es> einfach so im Tag-Namen vorkommen?
Ein Newline ist eine form von Abstand, um es in einen Tag zu packen
müsste man momentan das hier machen:
1
<tag\
2
name/>
Aber vielleicht ändere ich das noch, so dass man auch \n nehmen kann.
> Was ist mit Tabs?
Funktioniert genauso.
1
<tag\ name/>
> Ausrufzeichen am Anfang von Tag-Namen erlaubt? !--Hallo auch ein> erlaubter Tag-Name?
! am anfang ist momentan reserviert. Aber man kann ihn Escape:
1
<\!--Hallo/>
Ok, ! habe ich oben vergessen aufzuführen. Auf jeden fall, wenn es ne
spezielle bedeutung hätte, kann man es escapen. Aber vielleicht sollte
ich das mit dem <! nochmal überdenken, und da was anderes nehmen.
> DPA schrieb:>> * Keine HTML entities, statdessen alles utf8, und man kann #>> mit \ folgende 5 Zeichen (und nur diese) escapen: < ">\>> Wo bzw. wann genau muß man escapen, wann (darf man) nicht?
< ">!\ darf man immer escapen. Das vereinfacht die Serialisierung.
Andere Zeichen nicht. Momentan muss man nur escapen, wenn das Zeichen
eine spezielle Bedeutung hat. Aber auch dann, wenn es nur das erste
einer Sequenz mit spezieller Bedeutung sein könnte. z.B. bei <!>test \\<
123</!> ist day < escaped, weil es teil von </!> sein könnte. Das
vereinfacht das parsen. Es ist hingegen erlaubt, < in Tag Namen
unescaped zu lassen, da das dort keine spezielle Bedeutung hat:
1
<a<b> <!-->Das ist OK</!--> </a<b>
2
<a\<b> <!-->Das ist auch OK, und das selbe wie oben.</!--> </a\<b>
3
<\a> <!-->Das ist nicht OK, a kann nicht escaped werden.</!--> </\a>
4
<\\a> <!-->Das hier geht wieder.</!--> </\\a>
> DPA schrieb:>> * Text nodes werden explizit mit <!>text</!>gekennzeichnet.>> Die erste und letzte Leerzeile wird jeweils ignoriert. Damit>> ist immer klar, wo Abstände nur der Formatierung dienen, und>> wo diese zum Text / Inhalt gehören.>> Also gehören die Einrückungen in Deinem Bsp. zum Inhalt?
Wenn man innerhalb von <!> oder <!--> Text einrückt, ja, dann gehört es
dazu. Aber die Einrückung der Zeilen mit <!> und </!> selbst, und bei
allem ausserhalb der <!> tags, nicht. <!> kann auch keine anderen Tags
enthalten, das ist rein nur Text.
Es gibt noch einen kleinen quirk. Der Inhalt von <!> muss vom Tokenizer
nicht als ganzes zurückgegeben werden, dass kann auch als mehrere chunks
/ Tokens passieren, und ich gebe dort nirgends an, ob es ein neuer <!>
tag ist oder nicht. Der Parser setzt es dann zusammen, dadurch sollte
"<!>a</!> <!>b</!>" am ende genauso wie "<!>ab</!>" behandelt werden.
Andreas schrieb:> DPA schrieb:>> Ich rechne damit, dass es>> am Ende sehr solide wird. Programmfehler / crashes werde ich keine>> einbauen ;)>> Bei einem in C geschriebenen Parser für eine selbst ausgedachte> Markup-Sprache ist eine solche Aussage sehr gewagt.
Ich poste den Code, sobald er fertig ist, nochmal. Dann könnt ihr dann
da versuchen, einen Bug zu finden.
Momentaner Stand vom Tokenizer ist:
https://projects.dpa.li/git/?p=Y11.git;a=blob;f=Y11/src/ml666.c;h=9db9bce63362ad12b39ae66acdae787c50c397c0;hb=refs/heads/WIP
Aber eben, das ist noch unvollständig, einiges, insbesondere beim
escaping, ist noch nicht implementiert, und der line & column Wert ist
manchmal noch falsch (wobei der für den Parser selbst eigentlich eh
nicht wichtig ist, den habe ich nachträglich angeflanscht.), einiges
muss ich eventuell noch etwas umstellen (Vielleicht sollte ich das
switch in einen for loop packen statt umgekehrt, usw.). Den cleanup code
muss ich auch noch vervollständigen, da muss ich den Ring Buffer noch
freigeben. Auslagern in eine eigene Lib muss ich es später auch noch.
Also noch viel zu tun. Aber im grossen und ganzen geht es schon. (Dieses
Programm nimmt ml666 von stdin, und gibt die Token aus:
https://projects.dpa.li/git/?p=Y11.git;a=blob;f=Y11/src/main/ml666-test.c;h=2cb04587b2646c62e6e562e53eef00cbeda7508f;hb=refs/heads/WIP)
Ich halte auch nicht viel davon, weil ich keinen Vorteil sehe. Es löst
nicht in nennenswertem Maß Probleme, verursacht aber neue. XML gibt es
inzwischen seit fast einem viertel Jahrhundert und es ist bekannt und
verbreitet. In Java, C und Python habe ich es schon benutzt, teilweise
auch Varianten wie Binary XML.
Aber andererseits, warum sollte man sowas nicht mal machen? Es wird sich
mit ziemlicher Sicherheit nie verbreiten und in wenigen Wochen bis
Jahren nicht mehr benutzt werden, aber wenn man persönlich Spaß daran
hat, warum nicht? Ich wollte früher auch immer alles selber und besser
machen. Daraus habe ich auch gelernt.
Dussel schrieb:> Aber andererseits, warum sollte man sowas nicht mal machen? Es wird sich> mit ziemlicher Sicherheit nie verbreiten und in wenigen Wochen bis> Jahren nicht mehr benutzt werden, aber wenn man persönlich Spaß daran> hat, warum nicht?
So ist es.
Die eigentliche Frage ist doch, was durch die Diskussion darüber hier im
Forum erreicht werden soll?
Oliver
Oliver S. schrieb:> Die eigentliche Frage ist doch, was durch die Diskussion darüber hier im> Forum erreicht werden soll?
Ich nehme an, dass es das Ziel ist, dass sich diese eigene, viel bessere
Variante verbreitet und vielleicht auch der Traum, dass man irgendwann
in einer Reihe mit Namen wie Ritchie, Stroustrup, Torvalds und van
Rossum genannt wird. Das ist ja auch nicht schlimm. Träume dieser Art
hatte ich früher auch.
Allderings noch ein PS zum Thema:
DPA schrieb:> Momentaner Stand vom Tokenizer ist:> https://projects.dpa.li/git/?p=Y11.git;a=blob;f=Y11/src/ml666.c;h=9db9bce63362ad12b39ae66acdae787c50c397c0;hb=refs/heads/WIP
Ich bin ja kein Freund davon, dogmatisch etwas zu verbieten, auch wenn
es sinnvoll wäre, aber 44 gotos in einer einzigen Datei?
Das scheint mir doch ein sehr schlechter Stil zu sein. Es gibt (sehr
selten) sinnvolle Anwendungsfälle von goto, aber hier scheint es mir
doch eher fehlendes Verständnis, oder schlimmer, Überheblichkeit zu
sein.
Ich gebe aber zu, dass ich bei C-Programmierung nicht auf dem
aktuellsten Stand bin. Vielleicht hat ja goto inzwischen eine
Renaissance erfahren.
Dussel schrieb:> Ich bin ja kein Freund davon, dogmatisch etwas zu verbieten, auch wenn> es sinnvoll wäre, aber 44 gotos in einer einzigen Datei?
Es ist üblich, goto für den fehlerfall in Funktionen zu verwenden, das
macht auch der linux kernel so. Wegen den anderen gotos, In dem fall ist
das einfach einfacher. Es bietet sich bei einer state machine quasi an.
Ich hab 3 label: done, error, next_state. "done" und "error" gehen ans
ende. Ohne das müsste ich einige Layer an IFs, einige variablen, und
einige Brakes überall einsetzen (switch & for sind ja schon 2 ebenen,
und c hat leider kein labeled break wie z.B. JS, darum halt hier ein
goto). Auf jeden fall währe es fehleranfälliger, sich dafür mit
Kontrollstrukturen zu verrenken. Bei "next_state" ist es ähnlich. Es ist
momentan eher die Ausnahme, dass ich direkt wieder an den Anfang der
state maschine muss (nämlich, wenn zwar der state ändert, aber noch kein
token gematcht wurde), und ich habe keine labeled continues. Also muss
es halt ein goto tun. Ich finde das hier aber sowieso lesbarer, als
tonnenweise IFs und breaks.
Ich verwende sonst aber auch nicht einfach so goto. Ich glaube, das ist
die einzige Datei im Repo, wo ich gotos habe. Gotos müssen nicht schlimm
sein. Man muss sie nur richtig anzuwenden wissen. Aber dazu gabs schon
irgendwo einen Thread.
Dussel schrieb:> Oliver S. schrieb:>> Die eigentliche Frage ist doch, was durch die Diskussion darüber hier im>> Forum erreicht werden soll?> Ich nehme an, dass es das Ziel ist, dass sich diese eigene, viel bessere> Variante verbreitet und vielleicht auch der Traum, dass man irgendwann> in einer Reihe mit Namen wie Ritchie, Stroustrup, Torvalds und van> Rossum genannt wird.
Nö, es ist viel banaler. Ich hab einfach keinen, mit dem ich über sowas
reden kann / der sich für sowas interessiert. Ich rede aber eigentlich
gerne über solches zeug. Deshalb muss ich das halt im web machen.
Ich habe die Syntax nochmal ein wenig abgeändert. Ich nutze bei
Attributwerten nun ˋ statt ". <!> habe ich nun auch mit ˋ ersetzt. Für
Kommentare nehme ich jetzt // und /* */. Ich werte nur noch SP und LF
als Abstände (man kann also nicht mehr mit tab einrücken, oder Windows
Dateienden nutzen). Das verhalten mit der ersten / letzten Leerzeile bei
Text hab ich beibehalten, und auf Attributwerte ausgedehnt. Newlines
sind kein gültiges Escape Zeichen mehr, jetzt muss man \n nutzen. Ein
paar weitere Escapesequenzen hab ich auch noch hinzugefügt, unter
anderem auch \xNN für ein beliebiges byte. Ich bin mir noch am
überlegen, ob ich noch etwas für hex oder base64 kodierte Daten
hinzufüge. Und ich muss das alles noch Dokumentieren.
Den Tokenizer habe ich auch nochmal gründlich überarbeitet
(https://projects.dpa.li/git/?p=Y11.git;a=blob;f=Y11/src/ml666.c;hb=refs/heads/WIP).
Sachen umgestellt, code zusammengefasst, read syscalls reduziert, etc.
Viele der gotos haben sich dabei auch in Luft aufgelöst. Ich muss morgen
nochmal darüber schauen, eventuell noch das ein oder andere verbessern,
aber diese Version dürfte bereits vollständig und fehlerfrei sein.
Ja. Aber das ganze war sowieso noch nicht fertig & noch mitten in der
Designphase, wird also auch noch von niemandem benutzt.
Man könnte jetzt fragen, warum ich den Thread schon jetzt erstellt
hatte, und nicht erst, wenn es einigermass fertig ist. Aber das ist
simpel. Man kann nie früh genug Feedback bekommen. Jetzt kann man das
noch ändern. Später nicht mehr.
Ich finde deinen Spieltrieb toll.
Ich hatte früher auch Bock alles selber zu implementieren. Man lernt
eine Menge dabei.
Trotzdem halte ich es für sinnfrei.
Gehört das immer noch zu deinem Fairphone-Projekt?
Kein Wunder dass du nie fertig wirst wenn du immer neue Baustellen
aufmachst.
Es kommt halt drauf an wo deine Proritäten liegen.
Wenn es egal ist ob es jemals fertig wird, du mangelnde Qualität in Kauf
nimmst und gerne bastelst, dann mach weiter so.
Wenn du irgendwann fertig werden willst oder musst un das Ganze in
Jahren noch wartbar sein soll, nim was von der Stange.
Le X. schrieb:> Gehört das immer noch zu deinem Fairphone-Projekt?
Ich habe kein Fairphone, ich habe nur 2 Linux Phones (mit eigenen images
und eigener X11 basierter DE).
Ob es dazu gehört... das kann ich nicht einfach mit Ja oder Nein
beantworten.
X11 ist ziemlich tot, in dem Sinne, das Xorg im Grunde das Hauptprojekt
& Hauptimplementation ist, und man dort nichts grösseres mehr rein
bekommt. Zusätzlich gibt es Dinge, die ich damit nicht mehr umsetzen
kann. Und dann kommt noch dazu, dass Gnome angekündigt hat, bei GTK4 X11
support zu streichen. Mein WM Projekt ist darum momentan on-hold.
Wayland hingegen ist viel mehr lowlevel. Es ist auch keine
Implementation, es ist nur ein Protokoll. Implementationen gibt es
diverse, und noch keine hat sich endgültig durchgesetzt (wobei Gnome
hier den Heimvorteil hat, und ich kann Gnome absolut nicht leiden).
Wollte ich hiermit meine eigene DE machen, müsste ich eine eigene Shell
/ Compositor machen, dutzende Protokolle Implementieren, nur um ein paar
Fenster zu Plazieren. Das ist viel mehr Aufwand, als eine X11 WM.
Ausserdem mag ich Wayland nicht, es ist viel zu low-level, und überlässt
zu viel den Endanwendungen.
Was aber ein interessantes - und vermutlich nicht viel aufwendigeres -
Projekt wäre, wäre ein eigener Display Server, der nicht Xorg oder
Wayland ist. Aber das ist nicht genug. Wenn ich schon so was probiere,
gehe ich gleich 180° in die andere Richtung als Wayland. Die ML oben ist
eigentlich nur zu Test und Prototypen Zwecken. Ich habe die Ambition,
einen Display Server zu erstellen, der ein Object Model (Ähnlich dem
Browser DOM) hat, welches die Clients direkt über eine API verändern
können. Statt die Clients alles rendern zu lassen, lasse ich dann den
Server alles rendern, und die GUI Toolkits sollen nur das OM anpassen.
Ich hab es Satt dass jede Anwendung ihr eigenes Font Rendering macht,
ihre eigenen Ränder Zeichnet, sich um das Aushandeln der Formate für
Bild, Video und GL Kontexte kümmert, usw. Das wird alles wegabstrahiert,
wie beim Browser. X12 wird nicht kommen, aber vielleicht irgendwann mal
Y11?
Ich weiss noch nicht genau ob das was oder was das mal wird. (Vermutlich
nicht). Aber ich muss es wenigstens mal versucht haben. Und für den
unwahrscheinlichen falls dass das was werden sollte - dann mache ich
meine DE nochmal neu, diesmal auf meiner Basis.
DPA schrieb:> Ich habe kein Fairphone, ich habe nur 2 Linux Phones (mit eigenen images> und eigener X11 basierter DE).
Ja das meinte ich. Hatte da noch irgendwas im Kopf.
DPA schrieb:> Ich weiss noch nicht genau ob das was oder was das mal wird. (Vermutlich> nicht). Aber ich muss es wenigstens mal versucht haben.
Dann gl & hf.
Ich kann dein Vorhaben aus Bastlersicht nachvollziehen, mir wäre aber
für sowas meine Zeit mittlerweile zu schade.
Trotzdem solltest du zumindest bei so Alltäglichem wie MarkUp-Sprachen,
auf bewährtes zurückgreifen.
Sonst brennst du aus bevor dein proof-of-concept steht...
Jetzt habe ich noch Base64/Base64url und Hex Support direkt in den
Tokenizer eingebaut. Hier sind 4 Varianten den Text "test" anzugeben:
H`74 65 73 74` B`dGVzdA==` `test` `\x74\x65\x73\x74`
Jetzt habe ich den ml666 Teil mal in einen eigenen Branch ausgelagert,
daraus eine Library gemacht, und nutze es im Hauptprojekt nun per
submodul. Jetzt kann man also die ml666 lib komplett getrennt von allem
anderen builden.
Jetzt habe ich die Syntax formal per ABNF definiert:
https://projects.dpa.li/git/?p=Y11.git;a=blob;f=docs/syntax.abnf;hb=refs/heads/ml666
Ein railroad diagram gibts auch dazu: https://temp-s.s.abrecht.li/ml666/
(Dort fehlen aber noch die Kardinalitäten, und ich muss noch ein paar
Sachen aufräumen).
Die Semantik muss ich noch dokumentieren.
Und den Tokenizer muss ich auch noch dokumentieren. Den Parser teil zum
bestehen Tokenizer, der dann den Tree aufbaut, muss ich auch noch
machen.
Ein paar Kleinigkeiten fehlen also noch. Aber im insgesammt ist es nun
schon fast fertig.
Respekt für die Arbeit, erinnert mich an meine Anfänge mit PHP.
Damals gab es nur wenige und umständliche Frameworks, keins hat mir so
richtig gefallen, also dachte ich, schreib es doch lieber einfach
selbst...
Am Ende hatte ich dann so eine halb-fertige MySQL-Anbindung, eine
halb-fertige Template Engine, eine halb-fertige Session Steuerung, eine
halb-fertige irgendwas. Und auf das eigentliche Projekt keinen Bock
mehr.
Hoffentlich gelingt dir das besser!
Auf eine Problematik bin ich noch gestossen. Ich wollte noch ein Tool
machen, mit dem man z.B. zwischen ml666 und JSON Konvertieren kann, usw.
Aber ich bin in eine Inkompatibilität hineingeraten.
Bei mir sind Element Namen, Text, Attribut Namen, Attribut Werte, und
Kommentare, binär. Wenn man Text verwendet, sollte man UTF8 nehmen, aber
man muss nicht. Man könnte z.B. auch ein Katzenfoto als Element Name
nehmen, und solches Zeugs.
Die Strings in JSON hingegen nutzen UTF-8 und Unicode. Hat man eine
Bytefolge wie z.B. 0xFF 0x12, kann das in einem JSON String nicht
abgebildet werden.
Ich habe jetzt mehrere Optionen, damit umzugehen:
1) Im Tool lösen
1.a) Im Tool ignorieren. Immer als UTF-8 ausgeben, ungültige Zeichen mit
der ungültiges Zeichen Sequenz ersetzen, und die Limitation
Dokumentieren.
1.b) Gleich wie 1, ausser bei Text, dort erst prüfen ob es gültiges
UTF-8 ist, anderenfalls base64 ausgeben, und angeben, ob es utf8 oder
base64 ist.
1.c) Immer alles je nachdem in utf8 oder base64 speichern, und das im
JSON mit angeben, wie es kodiert ist. Ist dann aber schwieriger, damit
zu arbeiten.
1.d) Alle der oberen Möglichkeiten, einstellbar per Command Line
Optionen
2) Das ml666 Format anpassen
2.a) Tag & Attribut Namen müssen gültiges utf8 / Unicode sein. Attribut
Werte und Text müssen als utf8 oder Binär gekennzeichnet werden, ähnlich
wie in Python.
Momentan tendiere ich eher zu 1.d. Eigentlich ist eine Limitation von
JSON kein guter Grund, ml666 zu verkomplizieren. (Obwohl zu wissen, was
Text und was Binärdaten sind, schon manch mal nützlich sein könnte).
Aber was würdet ihr machen? Oder wie würdet ihr das am ehesten lösen?
DPA schrieb:> Bei mir sind Element Namen, Text, Attribut Namen, Attribut Werte, und> Kommentare, binär. Wenn man Text verwendet, sollte man UTF8 nehmen, aber> man muss nicht. Man könnte z.B. auch ein Katzenfoto als Element Name> nehmen, und solches Zeugs.
Und woher weiß man dann, was das ist? Ein großes Problem früherer
Formate war, dass oft kein Encoding oder mimetype oder sonstiges
hinterlegt war, das einem gesagt hat, wie die Daten zu interpretieren
sind. Wenn dein Format ein textbasiertes Format sein soll, dann muss es
auch ein Encoding haben und nicht aus Binärklumpen, die nicht als solche
markiert sind, bestehen.
DPA schrieb:> Bei mir sind Element Namen, Text, Attribut Namen, Attribut Werte, und> Kommentare, binär
Was ist die Idee dahinter?
Dann kann man dein "ml666" nicht mehr per Text-Editor bearbeiten, und du
könntest das ganze gleich durch ein Binärformat ersetzen, was du direkt
aus deinen Datenstrukturen serialisierst.
Da bist du gleich alle Escaping- und Encoding-Probleme los.
Εrnst B. schrieb:> DPA schrieb:>> Bei mir sind Element Namen, Text, Attribut Namen, Attribut Werte, und>> Kommentare, binär>> Was ist die Idee dahinter?> Dann kann man dein "ml666" nicht mehr per Text-Editor bearbeiten
Keineswegs. Das Format ist Text basiert. Die Datei selbst soll gültiges
utf-8 enthalten. Das bearbeiten mit dem Text-Editor ist also kein
Problem. Eventuell sollte ich das in der Syntax noch etwas strikter
sicherstellen.
Aber das ist vor dem Interpretieren der Escape Sequenzen. Mit diesen
kann man eine beliebige Byte folge abbilden. Nach dem Dekodieren hat mal
also erstmal binäre Daten. Wie diese Daten zu interpretieren sind, ist
dann der Endanwendung überlassen. Interpretiert diese etwas als Text,
sollte sie utf-8 verwenden. Aber momentan legt nicht das Format fest,
wie die Daten zu interpretieren sind, es erlaubt lediglich, eine
beliebige Baumstruktur einzulesen & zu speichern.
> könntest das ganze gleich durch ein Binärformat ersetzen, was du direkt> aus deinen Datenstrukturen serialisierst.> Da bist du gleich alle Escaping- und Encoding-Probleme los.
Also das will ich nun wirklich niemandem antun, in Binärsalat herum
stochern zu müssen.
Rolf M. schrieb:> DPA schrieb:>> Bei mir sind Element Namen, Text, Attribut Namen, Attribut Werte, und>> Kommentare, binär. Wenn man Text verwendet, sollte man UTF8 nehmen, aber>> man muss nicht. Man könnte z.B. auch ein Katzenfoto als Element Name>> nehmen, und solches Zeugs.>> Und woher weiß man dann, was das ist?
Was die Dekodierten Daten sind, legt die Anwendung fest. Wenn eine API
nur sagt, sie liefert JSON / XML, ohne weitere Infos, und ohne die Daten
gesehen zu haben, kann man damit auch nichts anfangen. Auch dort legen
die Anwendungen / Schnittstellen fest, was für Daten da drin sein
müssen, & wie die Datenstruktur aufgebaut ist. ML666 ist in der Hinsicht
nur etwas konsequenter.
Mein Problem ist wirklich nur, dass das so mit JSON inkompatibel ist,
weil JSON keine Binärdaten in Strings ablegen kann.
In ml666 habe ich die \x12 escape sequenz, wo man in hex eine Nummer
angeben kann. In JSON sind die strings utf8 kodiert, und es gibt keine
\x Escape Sequenz, dafür aber eine \u Escape Sequenz, die ein Unicode
Zeichen anhand seiner Unicode Nummer kodiert. Das Problem daran ist, ich
kann in ml666 z.B. diese Bytefolge codieren: `_\xFF_`. Aber diese
Escapesequenz ist kein gültiges utf-8, und kann deshalb in JSON Strings
nicht repräsentiert werden. Nun muss ich entscheiden, wie ich damit
umgehe.
Εrnst B. schrieb:> Dann kann man dein "ml666" nicht mehr per Text-Editor bearbeiten,
Das kann aber auch ein Pluspunkt sein, dann hätte er einen Grund einen
eigenen Texteditor für die eigene Auszeichnungssprache für seinen
eigenen Windowmanager für seinen eigenen Display-Server zu schreiben.
Frage: Warum willst du JSON-kompatibel sein?
Du mußt halt evt. Erweiterungen von JSON dann ebenfalls mitmachen, wenn
mal was Neues dazukommt. (Ich habe aber keine Ahnung, wie wahrscheinlich
das momentan ist.)
Ich würde jedenfalls versuchen, ohne solche Abhängigkeiten auszukommen.
Wühlhase schrieb:> Warum willst du JSON-kompatibel sein?
Die Möglichkeit nach JSON umzuwandeln ist extrem praktisch.
Es dafür bereits unendlich viele, extrem starke Tools gibt. Ich kann
dann z.B. das jq Tool nutzen. Und es gibt sicher auch tools, mit denen
man von dort nach CSV, XML, und was weiss der Geier was konvertieren
kann. Umgekehrt natürlich auch.
JSON ist als ML nicht besonders gut geeignet. Aber als Datenaustausch
und Manipulationsformat, ist es sehr mächtig.
Daniel A. schrieb:> Und es gibt sicher auch tools, mit denen> man von dort nach CSV, XML, und was weiss der Geier was konvertieren> kann.
Was dann wiederum die Frage in den Raum stellt: Wozu brauchst du dann
noch dein Datenformat, wenn CSV, XML oder JSON es auch könnten?
Bisher ging ich ja davon aus, daß dir etwas an diesen Formaten fehlt,
aber das kann ja dann nicht sein.
Wühlhase schrieb:> Was dann wiederum die Frage in den Raum stellt: Wozu brauchst du dann> noch dein Datenformat, wenn CSV, XML oder JSON es auch könnten?
Andere Formate haben andere Einschränkungen, sowie Vor und Nachteile.
Ich würde z.B. das Layout einer Webseite nicht mit JSON beschreiben
wollen, und ich würde Daten nicht mit HTML an eine REST API senden,
obwohl das alles machbar wäre.
Es ist aber trotzdem nützlich, zwischen den Formaten umwandeln, und
bestehende Tools verwenden zu können. Dann kann ich nachher z.B. solche
Sachen machen:
Nur mal so nebenbei, obwohl der Thread schon genug ausgeartet ist:
Schau dir mal https://fdik.org/yml/toolchain an. Haben schon andere
Leute genug Arbeit in durchdachte Loesungen reingesteckt.
YML2 ist eine der wenigen davon, die auch skalierbar fuer alle
moeglichen Szenarien bei mir funktioniert haben und abwaertskompatibel
bleiben. Bitte nicht noch ein anderes Format entwickeln, das mag zwar
lustig sein im Sinne von 'weil ich es kann', aber im Feld typischerweise
ein Rohrkrepierer.
NB: Ich bin nicht der Autor von YML2, nur Anwender.
Fitzebutze schrieb:> Bitte nicht noch ein anderes Format entwickeln
Aber YML2 kann keine Katzenbilder als Tags/Keys.
DPA schrieb:> Man könnte z.B. auch ein Katzenfoto als Element Name> nehmen, und solches Zeugs.
Endlich kann man seinen Quelltext mit Photoshop editieren.
Und vermutlich kommt bald mit der DML666 (DogMarkupLanguage666) ein
Fork, der auch das Einsetzen von Welpen-Bildern ermöglicht.
Momentan bin ich gerade dabei, mich um die UTF8 Validierung des ml666
Dokuments selbst zu kümmern. Also habe ich mal die Validierungsfunktion
im Anhang geschrieben (Falls jemand einen Blick darauf werfen kann, ob
ich was übersehen habe, das wäre gut).
Gewisse noncharacters, momentan nicht definierte code pages, und
überlang codierte Zeichen, lasse ich auch nicht zu.
Aber OMG, die Funktion ist komplex geworden. Was haben die geraucht, als
die UTF-8 gemacht haben? Warum haben die da Überlappungen gelassen, das
wäre doch nicht so schwer gewesen, den Offset der Codepages so zu
wählen, dass das nirgends passiert. Und diese non-characters hätte man
nie machen dürfen. Und wieso haben die UTF-16 Surrogates usw. einen
echten Zeichenwert gegeben, das hätte man doch rein als transparenter
Teil der der UTF-16 Kodierung lassen können, statt dem mist!
Mittlerweile ist JSON serialisierung / deserialisierung auch in meiner
Lib & tools drinn, jetzt kann man also hin und her konvertieren. Das
Schema musste ich aber etwas anpassen.
Einfach nur ein Array zu nehmen, wenn man ein Dokument mit mehreren
Entitäten im Toplevel serialisiert, ging nicht. Da konnte man bei
["B","TWlhdQo="] nicht zwischen 1 Entität bestehend aus base64 kodierten
Daten vs. 2 utf8 Entitäten im Dokument unterscheiden. Bei mehreren
Entitäten ist das jetzt ["D",["B","TWlhdQo="]].
Die Elemente und Kommentare hab ich auch auf Arrays umgestellt.
Kommentare als ["C","Der Kommentar"] und Elemente als z.B.
["E",[["key","value"],[["C","Kommentar"]]],["child element
1",["B","TWlhdQo="],"child element 3"]].
Dafür gibt es mehrere Gründe:
* Streamability. In ml666 kommt immer erst der Tag Name. Die APIs meiner
Library ist auch darauf ausgelegt, dass beim erstellen des Elements den
Namen schon kennt. Aber in JSON Objekten ist die Reihenfolge nicht
festgelegt, im schlimmsten fall hätte ich sonst alle Elemente erst
zwischenspeichern müssen, wenn die in der falschen Reihenfolge gekommen
wären.
* Ich kann direkt die Tokenizer API in meiner Library implementieren.
Damit bekommen alle Parser etc., die die nutzen, die Funktionalität
quasi gratis. Damit ist man viel Flexibler, als wenn ich die Parser API
reimplementiert hätte, oder gar direkt die Baumstruktur aufgebaut hätte.
* In den Attributen können Kommentare abgebildet werden
* Nicht-utf8 Daten in Attributnamen sind kein Problem mehr
* Kompakter
* Ich brauche im Parser keinen Speicher um mir zu merken, ob
übergeordnet ein Objekt oder ein Array war, ein Counter reicht
Einen Nachteil gibt es. Es ist ein klein wenig aufwendiger, das
weiterzuverarbeiten. Aber nicht extrem viel aufwendiger.
Das mit dem ["B",] kann überall vorkommen, also auch bei Kommentaren,
Attributnamen, Attributwerten, etc. Das ist einfach, weil es überall
auch nicht-utf8 kodierbare Daten geben kann. Das sagt aber nichts
darüber aus, ob es Text oder Binärdaten sind.
Naja, ganz 100% fertig ist es noch nicht. Die Behandlung von Kommentaren
ist noch nicht überall voll implementiert. Bei der ml666 Serialisierung
gibt es noch einen Edgecase, wo ich noch was ändern will. Beim parsen
behandle ich den UTF-8 BOM noch nicht. Ich muss nochmal checken, ob ich
die UTF16 BOM bei der UTF-8 Validierung zulasse (statt für den BOM zu
stehen können die auch ein echtes Zeichen repräsentieren, wusste ich
noch nicht, als ich den Validierungscode schrieb). Dann muss ich auch
mal noch einige test cases erstellen. Und die diversen APIs in meiner
Library muss ich auch noch Dokumentieren. Und dann gibt es noch ein paar
Sachen, die noch nicht Thread Safe sind, das muss ich auch noch fixen.
Ist aber alles machbar. Der schwierige Teil ist fertig, jetzt sind nur
noch diese Kleinigkeiten.
Es gibt zwar auch noch 1-2 Features, die ich in mein ml666 Tool einbauen
will. z.B. noch ein Serializer & Deserializer, btw. etwas was die API
implementiert, und z.B. ein Dokument oder eine Liste mit nur Daten
(Text, Binärdaten, usw.) nimmt, und einfach unescaped ausgibt. Wie die
raw modes bei jq. Und dann noch das selbe für Attributwerte eines
Elements. Ich kann da jq nicht dafür verwenden, dass kann nur utf8
(Beispiel, das hier gibt nicht /w== aus, sondern 77+9: jq -nj '"/w==" |
@base64d' | base64).
Eine erweiterte from von css und/oder xpath queries wäre auch noch was
cooles, aber eventuell etwas zu aufwendig. Aber dafür reicht jq vorerst
(da gehen Sachen wie z.B. '["D",..|select(try .[1]="image")]' um alle
Elemente mit dem Namen "image" auszugeben.).
Ein GC der auf die Baumstruktur API aufsetzt wäre auch noch nett.
Momentan haben die Nodes einfach nur einen ref counter, was jenachdem
etwas umständlich sein kann.
Aber das ist alles nicht nötig für das MVP.
🐧 DPA 🐧 schrieb:> Es gibt zwar auch noch 1-2 Features, die ich in mein ml666 Tool einbauen> will. z.B. noch ein Serializer & Deserializer, btw. etwas was die API> implementiert, und z.B. ein Dokument oder eine Liste mit nur Daten> (Text, Binärdaten, usw.) nimmt, und einfach unescaped ausgibt.
Jetzt hab ich das noch eingebaut. Das erleichtert einiges. Wenn ich
jetzt eine Datei für ein ml666 Dokument escapen will (für ein Attribut,
oder als Inhalt), kann ich das jetzt einfach so machen:
1
ml666 --input-format binary <fox.png
DPA schrieb:> * Keine Limitationen wo man welche Zeichen verwenden kann, ein > im tag> name? Kein Problem, einfach escapen!
Um das nochmal zu demonstrieren, codieren eines Bildes als ml666
Elementname:
Thread beobachten
Seitenaufteilung abschalten