XML hat so keine Zukunft. Es geht unter.

echter Troll

Da fällt mir so nebenher ein, das Office 11 von M$ nicht mehr die Dokumente in .doc etc. abspeichert, sondern in xml.

Meiner Meinung nach ein Vorteil, kann ich doch auf wirklich jedem Rechenr das Dokument lesen und bearbeiten.

rüdiger

BTW. Open Office macht das schon längst.

Daniel E.

Original erstellt von Prof84:
W3C [...] bewußt

Kaum :). Wenn ich die W3C-Seiten so lese, dann habe ich das Gefühl, dass das größtenteils Satire ist (http://www.w3.org/TR/xexpr/ ).

Lustig ist auch die gesamte Idee hinter XML[1]:
<Theorie>Viele Leute sind mit derzeitigen komplexen Programmen so ausgelastet, dass sie sich nicht mehr ihrer richtigen Arbeit zuwenden können und nichts vernünftiges mehr machen. Also machen sie es noch komplizierter (durch falsche Anwendung z.B.), womit sich am Schluß alle nur noch mit extrem komplexen Umgebungen beschäftigen und nicht mehr mit dem Problem an sich.
Im Vergleich dazu beschäfftigen sich nur wenige Leute mit der Lösung von Problemen, die aber mit diesen unnötig komplexen Systemen der Mehrheit interagieren müssen. Dazu müssen sie diese Systeme aber erst einmal verstehen, und während sie das verstehen, können sie sich mit nichts sinnvollen auseinandersetzten.
Der Teufelskreis der Komplexität ...
Wenn jemandem nichts mehr einfällt, dann macht man eine neue (ein paar 2000 Seiten starke) Norm[1], um andere Dinge zu vereinfachen, und merkt dabei garnicht, dass er damit die Situation verschlimmert.
</Theorie>

In XML ist einfach 80% zu überflüssig.

XML bietet mir mehrere Schichten[1] an, die immer das gleiche immer komplett anders machen. '<a type="b">c</a>': Hier kann 'a' als das 'aufrufende' Element[1] oder einfach ein syntaktisches Element betrachtet werden. [Wenn letzteres gilt, dann bekommt 'b' 'aufrufende' Bedeutung.]
Diese Attribute[1] sind überhaupt nur nötig, weil man es XML nicht anders sagen kann, dass man 'etwas' von mehreren Eingabedaten machen möchte. Darum bekommt man gerne sehr generische[1] Daten:

<foo do="bla" name="fasel">
  <foo do"bla2" name="fasel2">
    <foo ...>xxx</foo>
  </foo>
</foo>

'foo', dass eigentlich für die Struktur[1] der Dateien gedacht ist, ist eigentlich absolut sinnlos. Man hat also Müll strukturiert, denn Attribute _kann_ man eben in XML nicht strukturieren, was mir auch nicht ganz logisch erscheint. Ausserdem sind die End-Tags[1] sind absolut überflüssig und häßlich. Wenn man einfach Tags schachten könnte ...

Darum u.a. halte ich XML für die meisten Anwendungen suboptimal (lies: Konzeptionell kaputt), denn um diese Defizite von XML auszubessern braucht es wieder eine neue 'Technologie', zum Beispiel DTD[1] (Siehe oben zum Thema 'Komplexität' :)). Und XML als etwas revolutionär Neues hinzustellen erscheint mir auch ein wenig realitätsfern ...

Aber ein Standard macht ein Verfahren für den Durchschnitt erst praktikabel.

Ein Standard um jeden Preis ist auch nicht praktikabel, denn er leistet nicht das, was 'man eigentlich will'[tm]. Oder was hältst Du von der Norminierung von Schraubenlängen auf 25 cm :)? Ich glaub' es war letztens Volkard, der behauptet hat, dass ein Standard Innovation und damit bessere Technologien unterbindet.

[1]: 9 Treffer beim Buzzword-Bingo ;).

Cheers, Daniel

[ Dieser Beitrag wurde am 27.01.2003 um 18:12 Uhr von Daniel E. editiert. ]

BTW. Open Office macht das schon längst.

Mag sein, aber: Wer oder was ist Open Office bitteschön.
(läuft bei mir übrigens nicht )

Ich denke mal, das gerade durch MS xml gut verbreitet wird, weil ja jeder DAU eine hypermega_Schreibmaschiene braucht, die er nicht benutzen kann (mal abgesehen von strg+o,s und p ... evt. noch ALT+F4).

Wenn der DAU merkt, dass ohne probs andere Programme auch seine Office_Dateien bearbeiten können, wird er Office wohl schnell verlassen, da dann Magazine wie Computer-DAU etc. viele bessere Progs vorstellen werden, die dann aus dem Boden schießen werden.

Dann können wir auch nochmal über Open Office reden

Ich persönlich arbeite schon länger mit xml finde es gar mal schlecht, Daten damit abzulegen. Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

Marc++us

Original erstellt von <Luke>:
Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

Das ist mal eine Aussage, die den praktischen Vorteil schön auf den Punkt bringt...

Wobei natürlich die eingefleischten Leser von W3C wissen, daß DTD ja wieder out ist und wir inzwischen bei den XML-Schemata angekommen sind... damit kann man dann auch Parameter auf Wertebereiche etc. prüfen.

zum Thema MS Office und XML

altes .doc File :

binary crap
binary crap
...

neues .xml File :
<xml>
binary crap
binary crap
...
</xml>

Also mal wieder typisch MS....

Stefan

Spiegelschatten

Aha. So etwas wäre Sinnlos. Aber das sind wir ja seit Fenster 95 gewohnt.

Ich glaube jedoch nicht, dass die es so machen werden.
Das wird eher wie den Manifest-Dateien aussehen.

Daniel E.

Original erstellt von <Luke>:
Durch eine externe DTD kann ich meine Mitmenschen endlich mal dazu zwingen, meine Struktur auch einzuhalten, da es sonst Fehler hagelt.

DTDs saugen. Sie sind nicht mit den 'typischen' XML-Werkzeugen manipulierbar und das, was 'non-validating' Parsern machen müssen, um die Gültigkeit von Dateien zu überprüfen ist mehr als krank. Außerdem ist DTD statisch, was faktisch fast verbietet, dass ich Programme modularisieren, und damit eine neue Syntax in den Dateien erlauben kann, kann.

Marc++us

Original erstellt von Daniel E.:
Außerdem ist DTD statisch, was faktisch fast verbietet, dass ich Programme modularisieren, und damit eine neue Syntax in den Dateien erlauben kann.

Bitte erklären und mit Aussage verdeutlichen, ich verstehe nur Bonhoff.

OT: Daniel E. rede doch mal wie ein normaler Mensch. Hier ist nicht jeder so hochintelligent wie du.

Daniel E.

Marc++us: Ein Programm, dass verscheidene Plugins unterstützten will, will XML als Standarddatenformat benutzten. Der normale Weg für XML ist ja, dass man ein DTD (statisch) anlegt und daran habt sich dann alles zu halten, was dieses Programm an XML-Code jemals ausgibt.
Nun lädt der Benutzter ein Plugin hinzu, dass eine _neue_ Funktionalität in das Programm miteinbringt (was eigentlich der Sinn sein sollte :)). Diese neue Funktionalität lässt sich aber nicht mit den Mitteln des ersten DTDs beschreiben. Soweit das Problem :). Das DTD anzupassen ist offensichtlich die falsche Strategie, denn damit werden ja Dinge erlaubt, die das Programm 'an sich' nicht leisten will. Das einzig sinnvollen Vorgehen, die mir einfallen sind folgende: Jedes Plugin erzeugt ein eigenes Format, welches wieder durch ein DTD beschrieben werden muss. Oder man baut eine Hierarchie aus XML-Dateien (man bindet also andere Dateien ein), und verwendet immer nur das, dieser Datei zugeordnete DTD. Beide Ansätzte sind nicht wirklich schön, weil die Anzahl der Dateien, die betrachtet (und gewartet und bla) werden müssen extrem schnell ansteigt und weil der Schreiber von neuen Plugins nicht mehr die schöne Schnittstelle zum Programm benutzten kann, sondern er muss zumindest ein eigenes DTD basteln ...

Das hört sich reichlich theoretisch an aber in vielen dynamischen Sprachen ist das Problem viel unmittelbarer sichtbar, weil man durch das hinzufügen von Modulen/Funktionen programmiert :-/!

etechniker

Original erstellt von <John>:
OT: Daniel E. [...] Hier ist nicht jeder so hochintelligent wie du.

intelligent... lol

Marc++us

@etechniker: muß sowas sein?

@Daniel E.: ok, verstehe was Du meinst. Das ist letztlich ein ähnliches Problem wie der Versuch Objekte in relationalen Datenbanken zu speichern... die "baumigen" Hierarchien passen schlecht in flache Strukturen, wozu man die DTD zählen kann.

Allerdings bin ich mir nicht sicher, ob dieses Problem mit dem XML-Schema nicht lösbar wäre... dabei geht man für die Datenbeschreibung und Validierung von der DTD weg und verwendet eigene Tags zur Beschreibung der Inhalte. C# verwendet dieses Konzept für die Attribute. Ich hatte mal einen Workshop dazu besucht, wo einer von der Daimler-IT-Gruppe dargestellt hatte, wie sie mit diesem Konzept ihre Autos (ausgehend von der Schraube) als XML-Datei darstellen. Und da traten naturgemäß ebenfalls solche Dinge auf wie Erweiterungen und modulabhängige Abschnitte.

Bin aber solchen Anwendungen noch nicht konkret über den Weg gelaufen.

HolyFly

Original erstellt von <Doktor Prock>:
Ich finde Eure Diskussion durchaus interessant, jedoch seid ihr vom Thema abgekommen. Ihr konntet mir nicht wirklich wiederlegen, dass XML keine Zukunft hat. Also habe ich recht?

Also erstmal, weisst du gar nicht wo überall XML gerade fürs web eingesetz wird.

Mann schaue sich Cocoon (was den Java Programmierern bekannt sein dürfte) an.
Dieses Publishing Framework wandelt onthefly XML Daten in HTML / pdf um je
nach request.
Oftmals ist sowas auch selber implementiert vom Webanwendungsprogrammierer.

Ich habe mich auf Java & XML/XSL(t) spezialisiert und
habe eine ziemlich hohe Auftragslage damit.
Die Trennung von Layout und Daten wird durch XML
oft & gut gewährleistet zudem ist die Interoperabilität
ein weiterer Aspekt.

<oracle-modus>
XML ist die Zukunft des Internet. Denn das Internet
besteht aus mehr als dem Sichtbaren und wird sich immer weiter
zur Kommunikationsplattform entwickeln in denen der Datenaustausch
nicht mehr nur von Datenbank -> WebSeite -> Besucher geht sodern
noch weiter mit anderen Webanwendungen korrospendiert.
</oracle-modus>

Ja XML ist nicht offensichtlich denn was du vom server letztendlich
nach dem der XSLT Prozess vorbei ist serviert bekommst ist ebenso
html und zumeist auch mit .html endung.
XML spielt hinter den Kullissen schon jetzt eine starke Rolle.

Ein anderes Thema. XML als Medium um Service zu beschreiben
Webservices z.b. ist im moment das Thema überall.
In Sachen XML sind sich eingentlich alle grossen Firmen
einig das es die neuerung überhaupt ist

Marc++us

Gestern Abend habe ich noch mit einem neuen Tool gespielt, XMLSpy Enterprise Edition, v5. Wow! Ok, das ist natürlich erst einmal ein XML-Editor, da gibt's ja einige. Er kann zum einen aus einer Beispiel-XML automatisch eine DTD erstellen, das ist schon nett. Aber das tolle Feature: Codegeneratoren für C++, Java und C#.

Zum Beispiel für folgende XML-Schema-Datei (wer das nicht weiß: Schema ist eine Art verfeinerte DTD):

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="http://www.nanonull.com/LibrarySample" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.nanonull.com/LibrarySample" 
       elementFormDefault="qualified" attributeFormDefault="unqualified"> 
   <xs:element name="Library"> 
      <xs:complexType> 
         <xs:sequence> 
            <xs:element name="Book" type="BookType" 
                minOccurs="0" maxOccurs="unbounded"/> 
         </xs:sequence> 
      </xs:complexType> 
   </xs:element> 
   <xs:complexType name="BookType"> 
      <xs:sequence> 
         <xs:element name="Title" type="xs:string"/> 
         <xs:element name="Author" type="xs:string" maxOccurs="unbounded"/> 
      </xs:sequence> 
      <xs:attribute name="ISBN" type="xs:string" use="required"/> 
   </xs:complexType> 
</xs:schema>

erzeugt er mir solche Klassen, daß ich auf die Datei in dieser Form zugreifen kann:

Schreibend:

void Example()  
{  
    CLibraryType lib;  
    CBookType book;  
    book.AddISBN( _T("0764549642") );  
    book.AddTitle( _T("The XML Spy Handbook") );  
    book.AddAuthor( _T("Larry Kim") );  
    lib.AddBook( book );  
    CLibraryDoc doc;  
    doc.SetRootElementName(_T("http://www.nanonull.com/LibrarySample"), 
                           _T("Library") );  

    doc.SetSchemaLocation( _T("Library.xsd") ); // optional  
    doc.Save( _T("Library1.xml"), lib );  
}

bzw. lesend wie hier:

void Example2()  
{  
    CLibraryDoc doc;  
    CLibraryType lib = doc.Load( _T("Library1.xml") );  
    if( !lib.HasBook() )  
    {  
       cout << "This library is empty" << endl;  
       return;  
    }  
    for( int i = 0; i < lib.GetBookCount(); i++ )  
    {  
       CBookType book = lib.GetBookAt( i );  
       cout << "ISBN: " << book.GetISBN() << endl;  
       cout << "Title: " << book.GetTitle() << endl;  
       for( int j = 0; j < book.GetAuthorCount(); j++ )  
       {  
          cout << "Author: " << book.GetAuthorAt( j ) << endl;  
       }  
    }  
 }

Ich muß sagen, das ist ziemlich goil. Um zu prüfen, ob das Dokument valide gegen eine DTD oder ein Schema ist, muß ich nur ein doc.Validate() aufrufen - ist es ungültig, so wirft die Methode eine Exception.

Beim besten Willen, aber ich sehe hier dann in der Anwendung nicht mehr viele "bloatige" Sachen.

Genial. Am Montag geht die Bestellung raus, 999US$. Spart locker einige Tage Arbeit.

Btw, noch eine Feststellung: der VC7 stellt im Klassenbaum Namespaces mit einem eigenen Knoten [+] dar. War ein Tag der Entdeckungen...

[ Dieser Beitrag wurde am 01.02.2003 um 12:13 Uhr von Marc++us editiert. ]

Und was ist mit den ganzen Klassen die da verwendet werden?

CLibraryType
CBookType
...

Generiert der die auch oder muss man die selber schreiben oder wie es das?

Nitromaus

Welche Parser sollte man denn verwenden wenn man mit XML arbeiten will. Soweit ich weiß gibts da den MSXML oder? Was nimmt mann denn so. Selber schreiben is ja wohl ein bissl unsinig

Marc++us

@Folgeschaden: wird direkt generiert... die Namen korrespondieren mit den Tags aus der XML-Datei. Alles fix und fertig. Stützt sich auf dem MSXML4 ab, im Prinzip kann man den Codegenerator aber auch auf andere Implementationen abstützen. Du mußt keine Zeile programmieren. Alles in Namespaces gepackt, so daß man keine Verwirrungen hat. Einfach Objekte anlegen, load("xxx.xml") und ab geht die Post. Wirklich sehr durchdacht.

Die haben eine 30-Tage-Demo...

Prof84

@Marc++us:

Wetten - ich weiß, wo Du das gefunden hast? http://www.google.de/search?hl=de&ie=UTF-8&oe=UTF-8&q=%22binary+in+XML%22&btnG=Google-Suche&meta=

Marc++us

Kalt, völlig kalt.

Ich hatte eine Werbung dafür in der Post und bin auf die Homepage gegangen. Das Beispiel habe ich von meinem Rechner kopiert, das ist ein Beispiel aus der Online-Hilfe, das ich mal ausprobiert habe.