Alternative/Zukunft von SGML (?)

09/09/2013 00:24 マルコ#1
Hallo ihr lieben,

ich möchte mal wieder eine Umfragerunde starten.
Dieses Mal interessiere ich mich für SGML. SGML (Standard Generalized Markup Language) ist erstmal ein Begriff, der schwer zu verdauen ist. Was soll das sein? Um es kurz zu machen, SGML ist die Basis von HTML und XML.
Dem gegenüber steht die Object Notation.
Im Internet gibt es bereits viele Vergleiche XML vs. JSON. Dabei scheint JSON aber überall besser abzuschneiden, da es (laut einiger Argumentationen)
- weniger Overhead hat
- simplere (kleinere) Libraries braucht
- performanter und resourcensparender zu interpretieren ist

Das würde doch bedeuten, dass wir mit XML uns selbst ein Bein stellen. Führt man diesen Gedanken nun weiter, sollte man auch SGML in Frage stellen, denn darauf basiert XML. Auf SGML basiert aber auch HTML. Warum verwenden wir also noch HTML. Warum gibt es für HTML keine Alternative?

Diese Frage beschäftigt mich nun schon seit einiger Zeit. Deshalb habe ich mir folgendes überlegt:
Wieso sollten wir unsere Websites nicht in einer Object Notation schreiben? Und im gleichen Zug ein eindeutigeres Regelwerk zur Interpretation beilegen, so dass wir nicht den selben Browsersalat wie bei HTML haben?

Eigentlich wäre dies ja auch relativ einfach. Schon vorhandene HTML Elemente müssten nicht mal neu erfunden werden, sondern könnten weiterhin genutzt werden.
Nur mit eindeutigen Interpretationsregeln und in ON geschrieben.

Wie könnte das ganze aussehen?

Ein einfacher HTML Quelltext:
HTML Code:
<!DOCTYPE HTML>
<html>
<head>
  <meta charset="UTF8">
  <title>Foo</title>
</head>
<body>
  <div>
   <img src="someSrc" alt="bar">
  </div>
</body>
</html>
könnte in der neuen Sprache, die ich hier einfach mal Hyper Text Object Notation (HTON) nenne, so aussehen:

Code:
{
"VERSION":1,
"HTON":
{
  "HEAD":
  {
   "META":
   {
    "ATTR":
    [
     "CHARSET":"UTF8"
    ]
   },
   "TITLE":"Foo"
  }

  "BODY":
  {
   "DIV":
   {
    "IMG":
    {
     "ATTR":
     [
      "SRC":"someSrc",
      "ALT":"bar"
     ]
    }
   }
  }
}
}
Sicher, etwas ungewohnt, aber imo absolut nicht unübersichtlicher oder schwerer zu benutzen.


Nun schön und gut, sagen wir, ihr seid damit einverstanden. Was passiert dann mit CSS?
Anwort: Das selbe. CSS ist bereits wesentlich näher dran. Man könnte die Alternative nun, entsprechend zu HTON, Cascadian Style Object Notation (CSON) nennen. Schauen wir uns doch mal diesen kleinen CSS Schnipsel an:

HTML Code:
* {
  border: 0;
  margin: 0;
  padding: 0;
  position: relative;
}
und übersetzen ihn in CSON:

Code:
{
"VERSION":1,
"CSON":
{
  "*":
  [
    "border": 0,
    "margin": 0,
    "padding": 0,
    "position": "relative"
  ]
}
}
Dadurch, dass man diese Standards entsprechend definiert, könnte man z.B. wesentlich bessere WYSIWYG Editoren bauen.
Anfänger hätten hier einen kleinen Vorteil: sie müssen weniger lernen. Nja, aber das nur als unwichtigen Fakt am Rande^^^

Selbstverständlich ist mir bewusst, dass derzeit kein Browser der Welt diese Überlegungen unterstützt. Dennoch denke ich, dass mit entsprechender Community und Entwicklung (z.B. Browser, die das unterstützen, Plugins für gängige Browser, etc.) Aufmerksamkeit darauf gezogen werden könnte und ich es gar nicht so unwahrscheinlich finde, dass größere Firmen diese Alternative ernst nehmen.

Nja. Sinn dieses Threads ist aber vorerst zu evaluieren, wie ihr dazu steht, welche Ideen, Gedanken und Bedenken ihr hierzu äußern würdet.

Vielen Dank im Voraus für eure Kooperation!
09/09/2013 01:16 boxxiebabee#2
Hab jetzt nicht viel Zeit/Muse zum schreiben, aber mal ganz kurz mein Senf zu dem Thema.

Quote:
Originally Posted by マルコ View Post
Wieso sollten wir unsere Websites nicht in einer Object Notation schreiben? Und im gleichen Zug ein eindeutigeres Regelwerk zur Interpretation beilegen, so dass wir nicht den selben Browsersalat wie bei HTML haben?
Warum? Siehe andere Punkte. Eindeutiges Regelwerk? Das könnte man dann im Prinzip auch gleich für HTML machen, wäre kein Unterschied.

Quote:
Originally Posted by マルコ View Post
Sicher, etwas ungewohnt, aber imo absolut nicht unübersichtlicher oder schwerer zu benutzen.
Ich persönlich finds wesentlich unübersichtlicher. Vorallem weil es "nur" mit einer Klammer geschlossen wird. Man erkennt einfach schwerer wo ein Element genau geschlossen wird.

Quote:
Originally Posted by マルコ View Post
Dadurch, dass man diese Standards entsprechend definiert, könnte man z.B. wesentlich bessere WYSIWYG Editoren bauen.
Anfänger hätten hier einen kleinen Vorteil: sie müssen weniger lernen. Nja, aber das nur als unwichtigen Fakt am Rande^^^
Warum sollte man bessere WYSIWYG Editoren bauen können und weniger lernen? Es ist im Prinzip das gleiche. Nur eine etwas andere Schreibweise. Die unterschiedlichen Attribute, Elemente etc. bleiben ja vorhanden, da ändert sich nichts.

Quote:
Originally Posted by マルコ View Post
Aufmerksamkeit darauf gezogen werden könnte und ich es gar nicht so unwahrscheinlich finde, dass größere Firmen diese Alternative ernst nehmen.
Für größere Firmen definitiv keine Alternative. Browser Kompatibilität. Bis das mal alle relevanten Browser unterstützen sollten, und der Großteil der Nutzer eine aktuelle Version dafür haben vergehen erstmal etliche Jahre.
09/09/2013 01:16 Tasiro#3
Interessante Idee, so aber nicht einsetzbar.
JSON als Format ist in der Form gar nicht verwendbar, zwei DIVs und es ist kein (portables) JSON mehr. Es sieht außerdem... deutlich chaotischer aus. Es ist eine schlechte Idee, HTML einer solchen Transformation unterwerfen zu wollen. Wenn, dann ein ganz neues Seitenformat, welches nicht eine andere HTML-Schreibweise ist. HTML und CSS sind für ihre Verwendungszwecke erstellt worden. Da kommt JSON-Portierung nicht gegen an.
09/09/2013 01:36 マルコ#4
@Boxxiebabee:
Hmm, nunja, die Zeit spielt in erster Linie keine Rolle. Es soll keine Hopplahopp Lösung sein... Aber ich verstehe, was du bemängelst.

@Tasiro:
Ich habe bewusst nicht JSON gesagt. Natürlich müssten ein paar kleine Anpassungen hier stattfinden.

Vielen Dank für eure Antworten!
09/09/2013 02:07 Synatex#5
Ansatz gut - Kompatibilität wird Jahre brauchen. Obs jetzt umständlicher / einfacher ist kann man wohl kaum bewerten da das ganze einfach Gewöhnungssache ist. Ich find das ganze HTML an sich hat sich viel zu komisch entwickelt. Im Grunde ist das, was da im HTML passiert ja nichts als dumme Verschachtelung.. Den Ansatz deiner Idee finde ich gar nicht so schlecht, wenn man den mal von einem anderen Blickpunkt betrachten würde und die .HTML Dokumente wirklich NURNOCH die Struktur abbilden würden. Dann hätten wir:

index.html
HTML Code:
<html>
 <head>
  <title> <!-- Hier aufpassen -->
  <charset> <!-- Hier aufpassen -->
 </head>
 <body>
   <heading-main>
 </body>
</html>
index.elements
PHP Code:
{
"title""Dies ist meine erste Homepage"
"charset"
"utf-8",
"heading-main""Blablabla"

Ist im Grunde aber nur als würde man den Content noch einmal von der Struktur trennen. Normales Templatesystem.

Elemente die nur zur Struktur da sind würden in der einen Datei verweilen, Elemente welche jedoch ebenfalls oder nur Content besitzen in der anderen.
09/09/2013 02:58 マルコ#6
@Synatex: @Boxxiebabee:
Nunja, ich denke mal, dass man mit Highlighting einiges an Übersicht zurück gewinnt.

@Synatex:
Mit "dumme Verschachtelung" meinst du das selbe, wie Tasiro? Ein komplett neuer Ansatz, der grundlegend anders ist als HTML? So als Überlegung -> z.B. also nur absolut platzierte Elemente mit relativen Längen Angaben zur Größe des Browserfensters und evtl. Extremwerten? Hmm.
09/09/2013 07:54 Dark Sora#7
Was ich mich nun frage ist: warum ? 1. Find ich deine Idee wesentlich unübersichtlichier
2. Wäre das ne komplette umgewöhnung die man einfach nicht machen braucht
3. Sinn ?
09/09/2013 18:12 Synatex#8
Quote:
Originally Posted by マルコ View Post
Mit "dumme Verschachtelung" meinst du das selbe, wie Tasiro? Ein komplett neuer Ansatz, der grundlegend anders ist als HTML? So als Überlegung -> z.B. also nur absolut platzierte Elemente mit relativen Längen Angaben zur Größe des Browserfensters und evtl. Extremwerten? Hmm.
Da bist ja schon wieder bei CSS, wie genau man sowas umsetzen kann, keine Ahnung.

Quote:
Was ich mich nun frage ist: warum ? 1. Find ich deine Idee wesentlich unübersichtlichier
2. Wäre das ne komplette umgewöhnung die man einfach nicht machen braucht
3. Sinn ?
1.) Kein Grund, das ist Gewöhnungssache.
2.) Ebenfalls kein Grund, JavaScript hatte man auch nie wirklich gebraucht und trotzdem haben sich Leute von "PHP" abgewöhnt und entwickeln nun sogar JS Serverseitig, obwohl man es auch nicht unbedingt braucht.
3.) Neuentwicklung? Einfach mal ausprobieren.

Kompatibilität ist ja die weniger wichtigere Sache; theoretisch könnte man ja noch immer Parser zur Verfügung stellen die vorerst das "neue" Format in HTML umwandeln um Leuten sowas nahe zu bringen.

Was mir grad noch so als Hauptgrund für die Ablehnung deines Vorschlags einfällt @マルコ ist, dass du hier XML und JSON vergleichst. Beide sind nicht zum Strukturieren von Dokumenten im primären Vordergrund, sondern zum Speichern von Daten. Da ist es klar das auf kleinere und elegantere Lösungen zurückgegriffen wird.

Dass das ganze mal neu gemacht werden muss ist klar, 10 Jahre hinterlassen die Spuren - eine komplett neue, effektivere Methode, muss jedoch ebenfalls ein Schlaukopf hinterkommen und entwickeln :D
09/09/2013 22:27 Tasiro#9
Quote:
Originally Posted by Synatex View Post
1.) Kein Grund, das ist Gewöhnungssache.
[...]
Kompatibilität ist ja die weniger wichtigere Sache; theoretisch könnte man ja noch immer Parser zur Verfügung stellen die vorerst das "neue" Format in HTML umwandeln um Leuten sowas nahe zu bringen.
Mit deinem Vorschlag sieht das schon viel besser aus, nur würde ich JSON statt XML für die Struktur verwenden. Dann fehlt nur noch eine passende Javascript-Bibliothek, und schon lässt es sich verwenden. Die Suchmaschinen mögen das aber nicht...


Quote:
Originally Posted by Synatex
Was mir grad noch so als Hauptgrund für die Ablehnung deines Vorschlags einfällt @マルコ ist, dass du hier XML und JSON vergleichst. Beide sind nicht zum Strukturieren von Dokumenten im primären Vordergrund, sondern zum Speichern von Daten. Da ist es klar das auf kleinere und elegantere Lösungen zurückgegriffen wird.
XML ist für Dokumente, JSON für Daten. Nur weil XML die erste wirkliche Möglichkeit war, ein einheitliches Dateiformat verwenden zu können, wurde es auch da eingesetzt, wo JSON möglicherweise besser geeignet wäre.
Quote:
Originally Posted by srparish (Stack Overflow)
Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems.
Schöne Abwandlung.


Quote:
Originally Posted by Synatex
Dass das ganze mal neu gemacht werden muss ist klar, 10 Jahre hinterlassen die Spuren - eine komplett neue, effektivere Methode, muss jedoch ebenfalls ein Schlaukopf hinterkommen und entwickeln :D
Effizienz (Seitenaufbaugeschwindigkeit? Größe?) ist nicht allein das Ziel. Wenn es unleserlich ist, wird sich kaum ein Anhänger finden.
09/10/2013 05:16 マルコ#10
Ja, ich dachte sehr stark auch daran, dass JSON einfacher zu interpretieren ist. Klar sieht das so etwas konfus aus. Jedoch - meiner Meinung nach - weil Highlighting und gescheite Notation fehlen. Nja, war nur eine initiale Idee und ich möchte keinesfalls hier einen Schlussstrich setzen. Wenn hier jemand eine wirklich gute Idee aufbringt, dann gerne - immer raus damit.
So wie es aussieht, werde ich die Object Notation Idee dennoch weiter verfolgen - allerdings nicht als eigene Sprache, sondern tatsächlich als Speichervariante für HTML.
Ich persönlich bin aber trotzdem ein wenig unzufrieden mit HTML und suche deshalb so nebenher nach einer alternativen Lösung.
Die JS Bibliothek ist klar das Mittel zum Zweck, um alle Browser quasi sofort kompatibel zu machen. Dank Sitemap kann man aber auch hier ohne Probleme mit einem vernünftigen serverseitigen System alles suchmaschinengerecht in HTML wiedergeben. Bei SEs kommt es nicht auf korrekte Darstellung, sondern Informationen an - insofern wäre ein Format, das sich an solchen orientiert und eindeutig ist sicherlich eine gute Idee.

Nja, weitere Meinungen, Vorschläge und No-Gos mit der Idee? Vielleicht kann man aus genau diesen Argumenten etwas interessantes basteln. Muss nicht der neue Standard werden, aber ich will da mal was probieren und an den Mann bringen ;P