nicht angemeldet
Doctype - wozu ?
0 0 0 0 0 DTD - wozu ?
0 0
0 0
0
0
0
Doctype - wozu ?
Hi Html-Experten,
ich hab mal ne ganz einfache Frage: wozu <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">, wenn die Seiten genauso gut ohne funktionieren?
matthias
-
Hallo matthias,
ich hab mal ne ganz einfache Frage: wozu <!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">, wenn die
Seiten genauso gut ohne funktionieren?Steht doch da:
http://selfhtml.teamone.de/html/allgemein/grundgeruest.htm#dokumenttypGruesse,
CK-
Hi Christian!
Steht doch da:
http://selfhtml.teamone.de/html/allgemein/grundgeruest.htm#dokumenttypIch hatte jetzt ein bisschen mit XML zu tun, da werden ja für bestimmte Dinge die DTDs benötigt. Bei HTML/XHTML ist es wohl so, das die Browser die DTD-Datei sowieso nicht abfragen. Aber wie ist das im allgemeinen, bei XML, wenn ich hier eine HTTP-Verknüpfung angebe, wählen sich XML-Parser dann ins Internet ein und können die Datei sonst nicht parsen?
Grüße
Andreas-
Halihallo Andreas
Ich hatte jetzt ein bisschen mit XML zu tun, da werden ja für bestimmte Dinge die DTDs benötigt.
eigentlich für alle, nur machens die meisten nicht ;)
Bei HTML/XHTML ist es wohl so, das die Browser die DTD-Datei sowieso nicht abfragen.
ich bin mir selber nicht ganz sicher, glaube jedoch gehört zu haben, dass bei einem XHTML-Doctype auch der XML statt HTML Parser anspringt. Ich schätze jedoch, dass dies auch Browserabhängig ist.
Aber wie ist das im allgemeinen, bei XML, wenn ich hier eine HTTP-Verknüpfung angebe, wählen sich XML-Parser dann ins Internet ein und können die Datei sonst nicht parsen?
Die Parser interessieren sich IMO nur für wellformed, nicht für die Validität (evtl. optional doch?), wenn ich nicht irre. Es werden also im Normalfall keine externen Ressourcen eingelesen.
Viele Grüsse
Philipp
-
Hallo Philipp,
Aber wie ist das im allgemeinen, bei XML, wenn ich hier
eine HTTP-Verknüpfung angebe, wählen sich XML-Parser dann
ins Internet ein und können die Datei sonst nicht parsen?Die Parser interessieren sich IMO nur für wellformed, nicht
für die Validität (evtl. optional doch?), wenn ich nicht
irre. Es werden also im Normalfall keine externen Ressourcen
eingelesen.Das ist pauschal nicht beantwortbar, da vom Parser abhaengig.
Gruesse,
CK -
Hallo Philipp!
eigentlich für alle, nur machens die meisten nicht ;)
Ich frage mich hier ob es bei DTDs eher darum geht einen Standard für einen Datenaustausch zu haben, also wenn die Dokumente valide sind dann verstehen das auch alle Parser die damit zu tun haben, oder ob der Parser auch so was davon hat. Z.B. bei HTML hat man ja so zu sagen die DTD im Kopf(oder in SELFHTML ;-)), und die Browser halt so zu sagen mit einkompiliert(nicht die DTD sondern deren Logik), ich weiß z.B. was ich innerhalb von <table></table> zu verwenden habe, und wo genau #PCDATA stehen darf. Dasselbe weiß auch der Browser, udn bisher war es immer so das man was geschreiben hat, udn anstatt es zu validieren wurde es halt im Browser ausprobiert und wenn es in den meisten Brwsern lief war es "valide". Wozu das am Ende geführt hat kann man an einigen Browsern und vielen Internetseiten bewundern. Ich finde Bowser und HTML sind ein eigenes Kapitel was noch sehr weit von XML entfernt ist, weil man nicht mal eben alle Internetseiten valide machen kann und Monopolisten wie MS in seine Software-Entwicklung reinreden kann. Mir geht es jetz gerade eher im XML an sich.
Entweder ich entwickle einen Parser wie früher dei Browser, der die Struktur des XML-Dokumentes schon vorher kennt und entsprechend mit den Daten umgehen kann, oder ich entwickle einen Parser, der _immer_ eine DTD braucht, um mit den XML-Daten überhaupt was anfangen zu können, oder?ich bin mir selber nicht ganz sicher, glaube jedoch gehört zu haben, dass bei einem XHTML-Doctype auch der XML statt HTML Parser anspringt. Ich schätze jedoch, dass dies auch Browserabhängig ist.
Keine Ahnung, aber wenigstens könnsn die aktuellen Browser langsam ein wenig XML, soweit ich weiß ist XML beim (IE < 6 && IE >= 5) zwar möglich, aber nur sehr chlecht, (IE >=6 && Mozilla 1.1) sind da schon besser und können durchaus XML mit XSL darstellen. Kann man eigentlich serverseitig verläßlich erfahren ob der Client XML kann? Über den User_Agent wohl kaum, vielleicht über eine Test-XML-Seite in einem 1px Frame, die bei funktionierendem XML irgendwas auf dem Server nachläd oder sowas?
Die Parser interessieren sich IMO nur für wellformed, nicht für die Validität (evtl. optional doch?), wenn ich nicht irre. Es werden also im Normalfall keine externen Ressourcen eingelesen.
Was heißt "der Parser"? Ist es in XML nicht so dass es ganz viele verschiedene Parser gibt die bei Validität halt alle kompatibel sind? Ich meine Parser auch in dem Sinn einer Software die Daten per XML- austauscht...
Viele Grüße
Andreas-
Hallo Andreas,
eigentlich für alle, nur machens die meisten nicht ;)
Ich frage mich hier ob es bei DTDs eher darum geht einen
Standard für einen Datenaustausch zu haben, also wenn die
Dokumente valide sind dann verstehen das auch alle Parser
die damit zu tun haben, oder ob der Parser auch so was
davon hat.XML-Parser koennen z. B. keine Entities aufloesen (bzw. nur
beschraenkt, Unicode-Entities (&#<num>;) koennen aufgeloest
werden).Gruesse,
CK-
Hi,
XML-Parser koennen z. B. keine Entities aufloesen (bzw. nur
beschraenkt, Unicode-Entities (&#<num>;) koennen aufgeloest
werden).Doch, können sie. Diese Entities müssen nur definiert werden. Dies geschieht üblicherweise in der DTD, z.B. per <!ENTITY Auml "Ä">, also nichts anderes als in der HTML-DTD auch gemacht wird...
cu,
Andreas--
Der Optimist: Das Glas ist halbvoll. - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.-
Hallo MudGuard,
[...]
Guten morgen. Sowas passiert, wenn man die Nachricht aus dem
Kontext reisst.Gruesse,
CK
-
-
-
Hallo Andreas,
Ich frage mich hier ob es bei DTDs eher darum geht einen Standard für einen Datenaustausch zu haben,
Das ist auch eine der Gründe für eine DTD. Z.B. man kann Konfigurationsdateien für Software in XML schreiben (gibts ja auch schon zu genüge), damit ein Benutzer (Programmierer, etc.) die Software anpassen kann, muss er die XML-Datei verändern, was er und wie verändern kann, ist dann in der DTD als Regel für die XML-Datei festgehalten.
»»also wenn die Dokumente valide sind dann verstehen das auch alle Parser die damit zu tun haben, oder ob der Parser auch so was davon hat.
Ein Parser muss das Dokument nicht 'verstehen', er muss es nur anhand von Regel untersuchen. Für well-formed hat jeder Parser eine eigenes Modul, da wir eben nur auf die wenige Regel geachtet, die es für well-formed gibt. Wenn man eine DTD angibt, dann sind die Regel die der Parser für die Überprüfung des Dokuments benutzt in der DTD und diese Regel sind in den meisten Fällen komplizierter als die Regel für well-formed. Deshalb ist nicht jeder Parser auch ein validierender Parser, da die Logik für solche Überprüfungen einiges an Aufwand an Programmierarbeit erfordert.
Entweder ich entwickle einen Parser wie früher dei Browser, der die Struktur des XML-Dokumentes schon vorher kennt und entsprechend mit den Daten umgehen kann, oder ich entwickle einen Parser, der _immer_ eine DTD braucht, um mit den XML-Daten überhaupt was anfangen zu können, oder?
Wenn du, oder sonst wer, einen Parser schreiben kann, der die Struktur eines beliebigen XML-Dokuments schon im Voraus kennt, wird das die Welt verändern, denn das wäre schon weit über die Wahrscheinlichkeitsrechnung hinaus, es wäre nämlich Hellsehen.
Du mischst hier HTML mit XML. Für HTML mag es stimmen, dass die Browser im Vornhinein wissen müssen, wie sie die Elemente darstellen sollen, aber bei XML stimmt das nicht mehr, da XML im gegensatz zu HTML keine Layoutformatierung mit sich bringt. Was ja logisch ist, denn in XML kann ja jeder seinen eigenen Elementenvorrat erschaffen. Deshalb ist es für einen Parser nicht möglich zu wissen welche Elementen in einer XML-Datei vorkommen können und dabei hilft auch kein DTD, denn diese entwickelt man sie auch nach den eigenen Bedürfnissen. Es wäre sinnlos für XML einen festen Elementenzahl und Elementennamen zu erschaffen:- XML ist an sich keine konkrete Sprache, XML beschreibt die Regel anhand man seine eigene Sprache definieren kann.
- es gibt schon eine Sprache für Bildschirmdarstellung von Internetseiten: HTML.
Also die Aufgaben eines Parsers bestehen darain, dass er die XML-Datei aufbereitet d.h. für die Weiter verarbeitung zur Verfügung stellt, dass tut er in dem er die Datei "parst", d.h. dass er die strukturelle integrität der Datei prüft (well-formed und ggf.valide) und nach der Überprüfung diese struktur im Speicher abbildet.
»»langsam ein wenig XML, soweit ich weiß ist XML beim (IE < 6 && IE >= 5) zwar möglich, aber nur sehr chlecht, (IE >=6 && Mozilla 1.1) sind da schon besser und können durchaus XML mit XSL darstellen.
Das sind wiederum zwei Paar Schuhe, es ist was anderes ein XML-Datei zu parsen und es ist wiederum was anderes dann auch noch eine XSL-Transformation auszuführen.
Die Parser interessieren sich IMO nur für wellformed, nicht für die Validität (evtl. optional doch?), wenn ich nicht irre. Es werden also im Normalfall keine externen Ressourcen eingelesen.
Das ist so. well-formed 100%, valide optional.
Was heißt "der Parser"? Ist es in XML nicht so dass es ganz viele verschiedene Parser gibt die bei Validität halt alle kompatibel sind? Ich meine Parser auch in dem Sinn einer Software die Daten per XML- austauscht...
Umgekehrt. Es gibt viele Parser, die aber bei well-formed alle gleich sind, denn die Regel für well-formed müssen alle Parser zu 100% beherrschen, sonst wären sie gar keine Parser. Validitätsprüfung ist dagegen optional und nicht jeder Parser kann das. Ein validierender Parser muss selbstverständlich die DTD für die Validierung heranziehen, dazu muss er die DTD von dort holen wohin der Pfad im DOCTYPE zeigt (Lokal, Internet).
Ein XML-Parser oder XML-Prozessor ist eine Software, aber sie tauscht keine Daten aus.Grüße
Thomas-
Hallo!
Also ist die DTD wirklich nur dazu da um sicherzustellen, das die XML-Daten auch korrekt ausgewertet werden. D.h. wenn ich XML-Daten übertragen will, um sie zu parsen und z.B. in einer Datenbank schreiben will, sorgt die Validitätsprüfung nur dafür, dass die Daten genau so sind wie es jetzt mein Parser erwartet, so dass er keine Fehler beim Schreiben in die Datenbank macht, oder hat einen DTD noch einen anderen Grund?
Ich hatte mit Michael Schroepl kürzlich bzgl. EDIFACT diskutiert(</archiv/2002/12/32112/#m174033>). Da meinte er das der Vorteil einer XML-Lösung gegenüber EDIFACT darin bestünde, das man da durch die DTDs flexibler ist, d.h. das man hier genau definieren kann, was bestimmte Tags bedeuten, was bei EDIFACT nicht so ist, da weiß man wohl nicht zwangsläufig was bestimmte Elemente bedeuten(wenn ich das alles richtig verstanden habe!).
Aber dem nach was Du geschrieben hast ist das auch bei XML nicht so! Wenn der Parser eine fremde DTD verstehen soll, macht er das nicht automatisch, sondern man muß das auch in den Parser "hineinprogrammieren", oder? Also hätte das auch nur Sinn, wenn alle die gleiche DTD verwenden(aber das hatte Michael glaube ich auch gesagt).
Der Vorteil von XML gegenüber EDIFACT z.B. wäre dann nur der, das durch eine DTD ein einheitlichen Standard definieren werden könnte, an den sich dann alle Teilnehmer halten, und die dann alle untereinander kompatibel wären. Aber ich frage mich, wozu gibt es dann EDIFACT? OK, damals gab es glaube ich einfach noch kein XML, aber damit EDIFACT seine aktuelle Bedeutung im elektronischen Geschäftsdaten-Verkehr rechtfertigen kann muß es doch auch dort eine Art DTD geben, wo steht wie genau EDIFACT zu verwenden ist, damit das untereinander kompatibel ist, oder? Es kann ja nicht sein dass das alle Firmen untereinander für sich ausmachen, und man so für jede neue Firma einen eigenen EDIFACT-Parser scheiben müssen, oder? Sicher können einige großen Firmen aufgrund Ihrer Marktmacht anderen Firmen Ihren eigenen Standard aufzwingen, aber das kann doch nicht alles an "Standard" sein!
Aber wo gibt es so einen _echten_ Standard?Und gibt es bereits DTDs für den eletronischen XML-basierten Geschäftsdaten-Verkehr?
Viele Grüße
Andreas-
Hallo Andreas,
Also ist die DTD wirklich nur dazu da um sicherzustellen, das die XML-Daten auch korrekt ausgewertet werden.
wieso "nur"?
Gerade beim Datenaustausch ist es eines der wichtigsten Dinge, dass "korekte" Daten ankommenIch hatte mit Michael Schroepl kürzlich bzgl. EDIFACT diskutiert(</archiv/2002/12/32112/#m174033>). Da meinte er das der Vorteil einer XML-Lösung gegenüber EDIFACT darin bestünde, das man da durch die DTDs flexibler ist, d.h. das man hier genau definieren kann, was bestimmte Tags bedeuten, was bei EDIFACT nicht so ist, da weiß man wohl nicht zwangsläufig was bestimmte Elemente bedeuten(wenn ich das alles richtig verstanden habe!).
Man weiss das auch, aber eine EDIFACT-Nachricht ist nicht so gut lesbar, weil es hauptsächlich aus Zahlen und Buchstabencodes besteht. Das Format ist wesentlich kompakter und es ist zudem nicht so flexibel wie XML
Aber dem nach was Du geschrieben hast ist das auch bei XML nicht so! Wenn der Parser eine fremde DTD verstehen soll, macht er das nicht automatisch, sondern man muß das auch in den Parser "hineinprogrammieren", oder?
Ein Parser liest jede DTD und kann (falls validierend) gegen diese DTD auf Gültigkeit prüfen. Da muss man nix hineinprogrammieren. Man muss nur dafür sorgen, dass die DTD verfügbar ist: lokal oder im Netz.
Der Vorteil von XML gegenüber EDIFACT z.B. wäre dann nur der, das durch eine DTD ein einheitlichen Standard definieren werden könnte, an den sich dann alle Teilnehmer halten, und die dann alle untereinander kompatibel wären. Aber ich frage mich, wozu gibt es dann EDIFACT?
Aber wo gibt es so einen _echten_ Standard?
EDIFACT *IST* ein solcher Standardisierunsgversuch, um typische Geschäfsttransaktionen zu normieren. Bei großen Unternehmen auch sehr erfolgreich.
Und gibt es bereits DTDs für den eletronischen XML-basierten Geschäftsdaten-Verkehr?
Tausende. Das Problem ist eher es gibt zu viele.
Schau Dir doch mal ebXML (http://www.ebxml.org) an. Ein Versuch ein E-Business-Framework zu standardisieren, das auf XML basiert und damit auch für kleine und mittelständische Unternehmen attraktiv sein soll. Zudem arbeiten da zwei Organisationen dran mit, die beide langjährige Erfahrung in den entscheidenden Feldern haben: EDIFACT (UN/CEFACT) und XML (OASIS). Bei UN/CEFACT findest du auch mehr zu EDIFACT.
Gruß
Franz-
Hall Franz!
Man weiss das auch, aber eine EDIFACT-Nachricht ist nicht so gut lesbar, weil es hauptsächlich aus Zahlen und Buchstabencodes besteht. Das Format ist wesentlich kompakter und es ist zudem nicht so flexibel wie XML
"Gut lesbar" ist wie ich finde irrelevant. Es soll sich ja im Live-Betrieb keiner die Datenpakete angucken, das ist nur eine Vereinfachung für den Programmierer. Voen wegen Flexibilität, das ist zwar wahr das XML flexibler ist, aber mit der EInschränkung durch eine vorgegebene DTD ist es auch nicht mehr flexibler als EDIFACT, oder?
Ein Parser liest jede DTD und kann (falls validierend) gegen diese DTD auf Gültigkeit prüfen. Da muss man nix hineinprogrammieren. Man muss nur dafür sorgen, dass die DTD verfügbar ist: lokal oder im Netz.
Da hatet ich mich falsch ausgedrückt, ichmeien jetzt nicht direkt den eigentlichen XML-Parser, ich meine die Software die die XML-Daten z.B.in eine Datenbank schreibt. Die kann jeweils nur mit einer DTD verwendet werden, wenn eine andere DTD verwendet wird, muß man das durchaus umprogrammieren, oder?
Wenn ich in einer XML-Datei z.B. ursprünglich
<artikel>
<preis>232</preis>
</artikel>verwende, und das ganze auf
<artikel>
<nettopreis>204</nettopreis>
<bruttopreis>232</bruttopreis>
</artikel>umstellen möchte(bitte den Sinn nicht hinterfragen, ist ein blödes Beispiel)
dann kann man das zwar in der DTD global ändern, was aber nichts daran ändert, dass die Software jetzt nicht mehr auf <preis> sondern auf <nettopreis> und <bruttopreis> reagieren muß. Das hatte ich gemeint.Aber wo gibt es so einen _echten_ Standard?
EDIFACT *IST* ein solcher Standardisierunsgversuch, um typische Geschäfsttransaktionen zu normieren. Bei großen Unternehmen auch sehr erfolgreich.
Dazu zitiere ich mal aus dem oben verlinkten Posting von Michael:
||das ganze geschieht automatisch und EDIFACT ist ein Standard den die
||meisten größeren Firmen unterstützen.|Edifact mag ein Standard sein - aber soweit ich das mitbekommen habe,
|ein Standard auf der Abstraktionsebene von XML, nicht von HTML. Und
|was nützt Dir XML ohne die Definition einer DTD, an die alle
|Beteiligten sich halten? Aus Deiner Sicht ist diese DTD der
|gewünschte Standard - XML oder Edifact sind nur die
|Notationssprachen.Was mir gedanklich hier fehlt ist der eigentliche Standard in Form einer Art DTD, den die Firmen doch bräuchten um mit der "Beschreibungssprache" EDIFACT wirklich untereinander kompatible Daten auszutauschen.
Und gibt es bereits DTDs für den eletronischen XML-basierten Geschäftsdaten-Verkehr?
Tausende. Das Problem ist eher es gibt zu viele.
Das denke ich mir! Wenn jetzt 10% der Firmen Standard X, 20% Standard Y und wieder 17 % Standard Z, der Rest nur EDIFACT oder gar nichts, wie soll man dann Anwendungen schreiben können? Woran soll man sich halten? Wenn man mit allen Standards kompatibel sein will, braucht man eine eigene Schnittstelle zu jedem der einzelnen Standards, oder?
Schau Dir doch mal ebXML (http://www.ebxml.org) an. Ein Versuch ein E-Business-Framework zu standardisieren, das auf XML basiert und damit auch für kleine und mittelständische Unternehmen attraktiv sein soll. Zudem arbeiten da zwei Organisationen dran mit, die beide langjährige Erfahrung in den entscheidenden Feldern haben: EDIFACT (UN/CEFACT) und XML (OASIS). Bei UN/CEFACT findest du auch Danke Dir!
Viele Grüße
Andreas-
Hallo Andreas,
-------zitat-------
Also ist die DTD wirklich nur dazu da um sicherzustellen, das die XML-Daten auch korrekt ausgewertet werden. D.h. wenn ich XML-Daten übertragen will, um sie zu parsen und z.B. in einer Datenbank schreiben will, sorgt die Validitätsprüfung nur dafür, dass die Daten genau so sind wie es jetzt mein Parser erwartet, so dass er keine Fehler beim Schreiben in die Datenbank macht, oder hat einen DTD noch einen anderen Grund?
-------------------Ja und Nein. Validitätsprüfung und Parser sind keine getrennte Sachen, der Parser führt die Validitätsprüfung durch.
Die DTD sorg nicht dafür, dass die Daten korrekt ausgewertet werden, die DTD beinhaltet die Regel die die Struktur der XML-Datei beschreiben. Ein validierender Parser vergleicht die XML-Datei mit den Regel in der DTD und prüft so ob die Struktur der XML-Datei dieser DTD entspricht.
Beim Schreiben einer XML-Datei (vorausgesetzt du nimmst einen XML-Editor, der einen validierenden Parser benutzt) wird ebenfalls dieser Vergleich ausgeführt und falls man fehler in der XML-Datei machte, meldet der Parser eben einen Fehler.
Eine DTD ist auch dafür da, das in ihr die mögliche Elemente, Attribute, Elementkombinationen etc. festgehalten sind. So kann jeder auufgrund dieser DTD eine XML-Datei erzeugen, die den Anforderungen erfüllt (Anforderungen an einem Dokument, an einer Anwendung etc.) so wie eben jeder HTML-Seiten schreiben kann und dann überprüfen kann ob seine Seiten valide HTML-Dokumente sind.Man weiss das auch, aber eine EDIFACT-Nachricht ist nicht so gut lesbar,
"Gut lesbar" ist wie ich finde irrelevant. Es soll sich ja im Live-Betrieb keiner die Datenpakete angucken, das ist nur eine Vereinfachung für den Programmierer. Voen wegen Flexibilität, das ist zwar wahr das XML flexibler ist, aber mit der EInschränkung durch eine vorgegebene DTD ist es auch nicht mehr flexibler als EDIFACT, oder?Gut lesbar ist überhaupt nicht irrelevant! Es geht ja nicht nur um die Lesbarkeit als physische Tatsache, sonder auch um die Verständlichkeit und eine XML-Datei mit reichen semantischen MarkUp ist eine der aussagekräftigste Dokumente.
Dass DTDs in der XML-Welt irgendwann eine grenze der Flexibilität erreicht haben, ist bekannt; deshalb wird dort wo eine DTD nicht mehr genügend Spielraum bietet XML-Schema eingesetzt. XML-Schama basiert ihrerseits ebenfalls auf die Regel von XML.--------zitat-------------
Aber dem nach was Du geschrieben hast ist das auch bei XML nicht so! Wenn der Parser eine fremde DTD verstehen soll, macht er das nicht automatisch, sondern man muß das auch in den Parser "hineinprogrammieren", oder? Also hätte das auch nur Sinn, wenn alle die gleiche DTD verwenden(aber das hatte Michael glaube ich auch gesagt).
--------------------------Nein. In einem Parser ist nicht die/eine DTD programmiert, sondern die Logik eine DTD auszuwerten und die darin festgehaltene Regel dann bei der validierung einer XML-Datei anzuwenden. Ein guter Parser reagier auch auf Fehler in der DTD, d.h. er meldet wenn in der DTD ein Regel existiert, die nicht mit den Regel die für eine DTD gelten vereinbar ist. Wie man eine DTD schreibt ist eigentlich im SGML- und XML-Standard festgehalten.
Da hatet ich mich falsch ausgedrückt, ichmeien jetzt nicht direkt den eigentlichen XML-Parser, ich meine die Software die die XML-Daten z.B.in eine Datenbank schreibt. Die kann jeweils nur mit einer DTD verwendet werden, wenn eine andere DTD verwendet wird, muß man das durchaus umprogrammieren, oder?
Wenn ich in einer XML-Datei z.B. ursprünglich
<artikel>
<preis>232</preis>
</artikel>verwende, und das ganze auf
<artikel>
<nettopreis>204</nettopreis>
<bruttopreis>232</bruttopreis>
</artikel>Nein. Siehe oben, ein Parser muss die DTD ebensowenig im voraus kennen wie die Struktur der XML-Datei.
Aber wo gibt es so einen _echten_ Standard?
SGML, XML sind echte Standards.
Was mir gedanklich hier fehlt ist der eigentliche Standard in Form einer Art DTD, den die Firmen doch bräuchten um mit der "Beschreibungssprache" EDIFACT wirklich untereinander kompatible Daten auszutauschen.
Und gibt es bereits DTDs für den eletronischen XML-basierten Geschäftsdaten-Verkehr?
Wie Franz schon sagte, es gibt eine Menge, einge davon werden zentralisiert gepflegt: {link:http://www.idealliance.org/standards.asp] bzw. (u.a. für ebXML Arten) http://www.oasis-open.org/
Grüße
Thomas -
Hallo Andreas,
"Gut lesbar" ist wie ich finde irrelevant.
Im Prinzip ist das richtig.
Aber XML läßt sich eben leicht weitertransformieren in eine druckbare Rechnung z.B., die Werkzeugvielfalt und das Programmierer-Know-How nimmt zu. Ganz im Ggs. zu EDIFACT. XML lernt man schnell, eine komplexe DTD schon schwerer. Aber bei EDIFACT tut man sich schon schwer überhaupt das Grundprinzip zu begreifen: Transaktionen, Segmente usw.
Es soll sich ja im Live-Betrieb keiner die Datenpakete angucken, das ist nur eine Vereinfachung für den Programmierer. Voen wegen Flexibilität, das ist zwar wahr das XML flexibler ist, aber mit der EInschränkung durch eine vorgegebene DTD ist es auch nicht mehr flexibler als EDIFACT, oder?
Kommt drauf an, wie flexibel die DTD ist. Jedenfalls ist XML leichter änderbar (wenn es zu Änderungen kommt) als ein EDIFACT-Format. Aber Haupthemmnisse bei Änderungen können die Standardisierungsgremien sein...
Da hatet ich mich falsch ausgedrückt, ichmeien jetzt nicht direkt den eigentlichen XML-Parser, ich meine die Software die die XML-Daten z.B.in eine Datenbank schreibt. Die kann jeweils nur mit einer DTD verwendet werden, wenn eine andere DTD verwendet wird, muß man das durchaus umprogrammieren, oder?
Wenn ich in einer XML-Datei z.B. ursprünglich
<artikel>
<preis>232</preis>
</artikel>verwende, und das ganze auf
<artikel>
<nettopreis>204</nettopreis>
<bruttopreis>232</bruttopreis>
</artikel>umstellen möchte(bitte den Sinn nicht hinterfragen, ist ein blödes Beispiel)
dann kann man das zwar in der DTD global ändern, was aber nichts daran ändert, dass die Software jetzt nicht mehr auf <preis> sondern auf <nettopreis> und <bruttopreis> reagieren muß. Das hatte ich gemeint.Wenn du das so hart rein kodierst oder die Struktur komplett änderst hast du recht. In der Regel wirst du aber deine SW so designen, dass über Konfiguartionsmechanismen Deine SW auf sowas reagieren kann oder du nutzt Tools, die dich bei sowas in generischer Weise unterstützen. Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was mir gedanklich hier fehlt ist der eigentliche Standard in Form einer Art DTD, den die Firmen doch bräuchten um mit der "Beschreibungssprache" EDIFACT wirklich untereinander kompatible Daten auszutauschen.
EDIFACT ist nicht nur eine Syntax, sondern definiert ganz konkret Geschäftstransaktionen mit den notwendigen Messages. Eine Bestellung zum Bsp. kann aus verschiedenen definierten Messages bestehen und das ist standardisiert. Das ist wesentlich mehr als nur XML-Syntax. Da ist XML noch lange nicht, auch nicht ebXML oder vergleichbare Projekte. Schau dir den Hype um Web Services an. Da ist die Rede vom Aufruf von Methoden auf entfernten Servern über Firewalls hinweg (als wäre das bisher an den Administratoren gescheitert!). Hauptbeispiel: Börsenkursabfrage. Aber für langlaufende Transaktionen wie Bestellunge usw., Sicherheitsbelange u.a. gibts noch viel zu tun, bevor das wirklich in Unternehmen eingesetzt wird.
Das denke ich mir! Wenn jetzt 10% der Firmen Standard X, 20% Standard Y und wieder 17 % Standard Z, der Rest nur EDIFACT oder gar nichts, wie soll man dann Anwendungen schreiben können? Woran soll man sich halten? Wenn man mit allen Standards kompatibel sein will, braucht man eine eigene Schnittstelle zu jedem der einzelnen Standards, oder?
Ja, zumindest benötigst Du eine Art von Integration. Ob die nun Point-zu-Point ist oder auf Maping basiert oder was auch immer. Was meinst du warum die meisten Probleme in größeren Unternemen Integrationsprobleme sind. Irgendwie geht es doch immer um Schnittstellen in der IT. Außer sowas hat Erfolg und setzt sich auf der ganzen Welt durch (woran ich nicht glaube ;-): http://www.oasis-open.org/committees/ubl/.
Gruß
Franz-
Hallo Franz!
Aber XML läßt sich eben leicht weitertransformieren in eine druckbare Rechnung z.B., die Werkzeugvielfalt und das Programmierer-Know-How nimmt zu. Ganz im Ggs. zu EDIFACT. XML lernt man schnell, eine komplexe DTD schon schwerer. Aber bei EDIFACT tut man sich schon schwer überhaupt das Grundprinzip zu begreifen: Transaktionen, Segmente usw.
Aber Transaktionen(damit meinst Du doch das z.B. eine Bestellung vom Gegenüber bestätigt werde müssen, oder?), haben ja nicht mit Edifact oder XML zu tun, das ist doch eher eine Frage der Semantik ob ich möchte das meine Bestellung auch bestätigt wird. Das _muss_ es dann auch in XML-basierten Standards geben, ohne solche Bestätigungen wird man das wohl nirgendwo in kritischen Bereichen durchsetzen können.
Wenn du das so hart rein kodierst oder die Struktur komplett änderst hast du recht.
was heißt "hart reinkodieren"? Was soll ich sonst machen wenn sich was an den Daten ändert?
In der Regel wirst du aber deine SW so designen, dass über Konfiguartionsmechanismen Deine SW auf sowas reagieren kann oder du nutzt Tools, die dich bei sowas in generischer Weise unterstützen.
Meinst Du sowas wie eine Oberfläche in der man manuell, also z.B. pber ein webinterface die Zuordnung von Daten zu Tabellen verändern kann? Kann mir nicht so genau vorstellen wie Du das meinst.
Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was heißt mapping? Ich will einen "Datensatz" den ich als XML-Datei habe in eine relationale Datenbank eintragen, meinst Du da brauche ich gar keine eigene Software für schreiben? Gibt es sowas für MySQL oder postGreSQL? Gibts sowas auch für die Gegenrichtung?
Ja, zumindest benötigst Du eine Art von Integration. Ob die nun Point-zu-Point ist oder auf Maping basiert oder was auch immer.
Was ist da der Unterschied?
Vielen Dank und schöne Grüße,
Andreas
-
Hallo Andreas,
Aber Transaktionen(damit meinst Du doch das z.B. eine Bestellung vom Gegenüber bestätigt werde müssen, oder?), haben ja nicht mit Edifact oder XML zu tun, das ist doch eher eine Frage der Semantik ob ich möchte das meine Bestellung auch bestätigt wird. Das _muss_ es dann auch in XML-basierten Standards geben, ohne solche Bestätigungen wird man das wohl nirgendwo in kritischen Bereichen durchsetzen können.
Also mal vorweg: ich bin auch nicht der EDI-Experte ;-)
Bei den EDI-Standards wird allerdings eine Transaktion wie z.B. eine Bestellung durch ein bestimmtes Set von Nachrichten, die da hin und her gehen müssen/können definiert. Diese Nachrichten müssen dann wieder ein bestimmtes Format haben usw.Folgendes scheint mir nicht so schlecht (und kurz genug zu mal eben durchlesen) zu sein zum Verhältnis EDI und XML: http://www.seals.com/download/XML_eBusiness_4.pdf
In der Regel wirst du aber deine SW so designen, dass über Konfiguartionsmechanismen Deine SW auf sowas reagieren kann oder du nutzt Tools, die dich bei sowas in generischer Weise unterstützen.
Meinst Du sowas wie eine Oberfläche in der man manuell, also z.B. pber ein webinterface die Zuordnung von Daten zu Tabellen verändern kann? Kann mir nicht so genau vorstellen wie Du das meinst.Ja, sowas in der Art. Oder auch eine XML-Datei.
Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was heißt mapping? Ich will einen "Datensatz" den ich als XML-Datei habe in eine relationale Datenbank eintragen, meinst Du da brauche ich gar keine eigene Software für schreiben? Gibt es sowas für MySQL oder postGreSQL? Gibts sowas auch für die Gegenrichtung?Ja, gibt es auch für die Gegenrichtung.
Ich weiss, das Oracle, DB2 und MS SQL Server solche Tools haben. Aber da arbeite ich mich gerade erst praktisch ein. Vieles geht da auch nicht so locker wies klingt.
Habe jetzt nichts parat, aber es gibt bestimmt auch irgendwelche Tools im Netz, die Dir aus einem XML-Dokument ein SQL-Statement generieren.
Aber spannend wird natürlich erst, wenn man ein XML-Dokument einfach als Objekt wegspeichern kann und dann z.B. mit XPath oder XQuery darin suchen kann.Ok, jetzt ist genug spekuliert ;-)
Ja, zumindest benötigst Du eine Art von Integration. Ob die nun Point-zu-Point ist oder auf Maping basiert oder was auch immer.
Was ist da der Unterschied?Mit Point-zu-Point meinte ich zwei Partner einigen sich auf genau eine Schnittstelle. Mit Mapping meinte ich, das irgendein Programm/Tool zwischen den Schnittstellen die Daten transformiert in das gewünschte Format.
Gruß und gute Nacht
Franz -
Hallo Andreas,
Wenn du das so hart rein kodierst oder die Struktur komplett änderst hast du recht.
was heißt "hart reinkodieren"? Was soll ich sonst machen wenn sich was an den Daten ändert?Eine Logik schreiben, die eine DTD für sich einlesen kann und quasi alle mögliche Kombinationen der Elemente anhand der DTD-Angaben errechnet und diese dann mit der XML-Datei vergleicht.
Genau das machen validierende Parser, in ihnen ist keine DTD hard-coded, sonder eben nur eine Logik, die das oben beschriebene macht.Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was heißt mapping? Ich will einen "Datensatz" den ich als XML-Datei habe in eine relationale Datenbank eintragen, meinst Du da brauche ich gar keine eigene Software für schreiben? Gibt es sowas für MySQL oder postGreSQL? Gibts sowas auch für die Gegenrichtung?Mapping heisst "Abbilden". Viele DBs bieten dafür Tools bzw. APIs an. Du kannst diese dann nützen um z.B. eine SQL-Abfrage an die DB zu senden und die Antwort in eine XML-Datei zu schreiben. Bzw. du kannst eine XML-Datei an/durch die API senden und sie dann als Tabelle in der DB abzulegen. Es gibt auch open-source tools, die
solche DB-APIs ansrechen können.
(dam davon abgesehen, dass du eine XML-Datei auch als BLOB in der DB speichern kannst)Grüße
Thomas
-
-
-
-
-
-
Hallo, Thomas,
nur ein paar kleine unwichtige Anmerkungen... *smirk*
Du mischst hier HTML mit XML. Für HTML mag es stimmen, dass die Browser im Vornhinein wissen müssen, wie sie die Elemente darstellen sollen
Jein, sie haben ein Stylesheet dafür, das stimmt. Wie Browser HTML anzeigen, ist jedoch nirgendwo festgelegt, denn HTML ist ursprünglich eine anzeigeunabhängige Sprache. Mit dem CSS-Beispielstylesheet wurde ein informeller Konsens dokumentiert und die grafische Anzeige über das Boxmodell normiert - innerhalb dieser Regeln des Boxmodells ist es aber alleinig die Angelegenheit des Browsers, wie das Markup umgesetzt wird.
aber bei XML stimmt das nicht mehr, da XML im gegensatz zu HTML keine Layoutformatierung mit sich bringt.
Nein, (X)HTML bringt auch keine Layoutformatierungen »mit sich«, der Browser hat wie gesagt nur ein Stylesheet dafür. Erst durch das browserinterne Anwenden von Styles wird eine grafische Widergabe ermöglicht, ansonsten ist XHTML (Strict, ohne Präsentationselemente) universell und ein wahres Kind von XML, worin dessen Stärke liegt.
Was ja logisch ist, denn in XML kann ja jeder seinen eigenen Elementenvorrat erschaffen.
Ja, das ist aber kein Grund dafür, dass die Browser ein HTML-Dokument meist sehr ähnlich visualisieren. Noch heute gibt es in den Details Unterschiede, sodass dasselbe Dokument auch ohne zusätzliche Autorenstyles von verschiedenen Browsern verschieden gerendert wird.
Dass ein grafischer Browser ein h1-Element größer darstellen wird und ein table-Element samt Kindelementen als Tabelle, ist natürlich selbstverständlich, aber dies ist nur eine spezielle Art der Interpretation des Codes. Ein Textbrowser beziehungsweise ein anderes Medium wird dies komplett anders handhaben. Zu behaupten, ein HTML-Dokument enthalte in der Regel implizit keine Informationen über die Art der Visualisierung, wäre nicht ganz richtig, denn p für paragraph determiniert mehr oder weniger die Anzeige, aber eben nur implizit, im Markup selbst steht nirgendwo, wie das Dokument visuell wiedergegeben wird. Sollte es zumindest nicht, wenn es sich *Hyper*text oder XML-Dokument nennen will.
Natürlich lässt sich nicht alles mit Styles beschreiben, dennoch steht in keinem Standard und schon gar nicht im Markup, wie Browser Hyperlinks kennzeichnen müssen. Kein XML-Markup definiert die Formatierung, es sei denn, man schreibt eine Seitenbeschreibungssprache in XML und mixt Datenorganisation und Datenanzeige... Die Transitional-Varianten von (X)HTML sind solche Sprachen, XML und damit XHTML ist aber nicht dafür gemacht HTML *ursprünglich* auch nicht.
es gibt schon eine Sprache für Bildschirmdarstellung von Internetseiten: HTML.
Die einzige existente Sprache, welche tatsächlich für die Bildschirmdarstellung von Webseiten entwickelt wurde, ist CSS.
langsam ein wenig XML, soweit ich weiß ist XML beim (IE < 6 && IE >= 5) zwar möglich, aber nur sehr chlecht, (IE >=6 && Mozilla 1.1) sind da schon besser und können durchaus XML mit XSL darstellen.
Das sind wiederum zwei Paar Schuhe, es ist was anderes ein XML-Datei zu parsen und es ist wiederum was anderes dann auch noch eine XSL-Transformation auszuführen.
Steht zwar nicht im direkten Bezug zu deiner Aussage, aber weil Andreas meinte, Browser stellen XML-Dokumente »mit« XSLT dar:
Im Endeffekt wenden Browser nach der Transformation auch wieder interne Styles an - nur halt auf das Produkt der Transformation, weil sie für HTML ein Standardstylesheet haben, was sie für eine beliebige andere XML-Sprache nicht haben (ich weiß auch nicht, ob bspw. Ruby oder MathML über das CSS-Boxmodell komplett interpretierbar ist, ich denke einmal nicht). Hinzu kommen die dem Browser geläufigen »Regeln« zur Kennzeichnung von Hyperlinks u.ä.Ansonsten natürlich ACK. Wir meinen auch eigentlich das Gleiche, scheint mir. *fg*
Grüße,
Mathias--
Mein Leben, ein Leben ist es kaum, / Ich gehe dahin als wie im Traum.
Wie Schatten huschen die Mensch hin, / Ein Schatten dazwischen ich selber bin.
Und im Herzen tiefe Müdigkeit - / Alles sagt mir: Es ist Zeit ...
(Theodor Fontane, Mein Leben)-
Hallo Mathias,
nur ein paar kleine unwichtige Anmerkungen... *smirk*
Schön, aber jetzt muss du mir noch erklären wo der Unterschied zwischen dem was du gesagt hast und dem was ich gesagt habe ist.
Ansonsten natürlich ACK. Wir meinen auch eigentlich das Gleiche, scheint mir. *fg*
Ah so. ;-)
-------
PS:es gibt schon eine Sprache für Bildschirmdarstellung von Internetseiten: HTML.
Die einzige existente Sprache, welche tatsächlich für die Bildschirmdarstellung von Webseiten entwickelt wurde, ist CSS.
Darüber ließe sich durchaus streiten. :-)
Grüße
Thomas
-
-
-
Hi,
Die Parser interessieren sich IMO nur für wellformed, nicht für die Validität (evtl. optional doch?), wenn ich nicht irre. Es werden also im Normalfall keine externen Ressourcen eingelesen.
Wenn das XML aber Entities enthält, muß die DTD (in der diese enthalten sind) doch gelesen werden...
cu,
Andreas--
Der Optimist: Das Glas ist halbvoll. - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig. -
Hallo Philip,
da ich gerade wieder viel mit BMEcat rummache, und mich wieder grün und schwarz über die DTDs ärgere:
eigentlich für alle, nur machens die meisten nicht ;)
es gibt auch Schemas, die vorzuziehen sind. Die sind IMO besser lesbar, weil sie eben auch in XML geschrieben sind.
Unsere kleinen Konfigurationsdateien haben übrigens weder DTD noch Schema. Wozu auch, die sind nur für uns. Und können so schneller erweitert oder umgebaut werden, wenn es nötig sein sollte.
Gruß,
Martin
-
-
Moin!
Ich hatte jetzt ein bisschen mit XML zu tun, da werden ja für bestimmte Dinge die DTDs benötigt. Bei HTML/XHTML ist es wohl so, das die Browser die DTD-Datei sowieso nicht abfragen.
Die DTD wird nicht unbedingt geladen (es steht ja auch nicht drin, welche Bedeutung oder Sonderfunktion gewisse Elemente haben), aber die Angabe des DOCTYPE ist dennoch wichtig: Die neueren Browser schalten in den standards-compliant mode, wenn sie einen passenden DOCTYPE finden. Und das ist eine gute Sache. :)
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
-
-
Hallo CK,
das habe ich schon gelesen: http://selfhtml.teamone.de/html/allgemein/grundgeruest.htm#dokumenttypaber, wenn ich nun schreibe <frameborder="no"> sagt der Validator, daß das ungültig ist. Was macht man, wenn man auf dieses Attribut nicht verzichten kann?
Gruß
matthias
-
Hallo!
aber, wenn ich nun schreibe <frameborder="no"> sagt der Validator, daß das ungültig ist. Was macht man, wenn man auf dieses Attribut nicht verzichten kann?
Was hast Du denn für einen Doctype verwendet? Denselben wie hier: http://selfhtml.teamone.de/html/frames/eigenschaften.htm#rahmen?
Grüße
Andreas-
Hallo!
Was hast Du denn für einen Doctype verwendet?
folgenden Doctype habe ich verwendet:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">Gruß
Matthias
-
Hallo!
folgenden Doctype habe ich verwendet:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">[ ] Du hast auf den Link geklickt und das was da steht gelesen?
Grüße
Andreas-
Hallo Andreas,
[ ] Du hast auf den Link geklickt und das was da steht gelesen?
Danke für den Hinweis, ich habe es gelesen. Also da steht ja unter anderen: "...HTML-konform zu schreiben, und die weit verbreiteten Browser ignorieren Ihre Angaben, oder Sie schreiben für die Browser und verzichten auf die HTML-Konformität..." Das ist doch genau der Punkt: Welchen Grund gibt es, html-konform schreiben, wenn die Browser es dann falsch (falsch = anders als vom Autor beabsichtigt) anzeigen?
Gruß
Matthias
-
Hallo!
Danke für den Hinweis, ich habe es gelesen. Also da steht ja unter anderen: "...HTML-konform zu schreiben, und die weit verbreiteten Browser ignorieren Ihre Angaben, oder Sie schreiben für die Browser und verzichten auf die HTML-Konformität..." Das ist doch genau der Punkt: Welchen Grund gibt es, html-konform schreiben, wenn die Browser es dann falsch (falsch = anders als vom Autor beabsichtigt) anzeigen?
IMHO keinen ;-) Weiß jemand ob das _alle_ Browser nicht verstehen, also auch aktuelle Mozilla und IE 6? (kann das leider mangels installierer Browser nicht testen).
Aber:
Das ist eine von mit neuen Browserversionen immer weniger Ausnahmen. Udn ich finde es ganz praktisch wenn ich nicht 1/3 meiner Zeit damit verwenden muß die Seite auch in allen verschiedenen Browsern mit allen möglichen und unmöglichen Tricks gleich aussehend zu bekommen. Ich versuche die Seite bis auf die wenigen oben ganannten Ausnahmen valide zu bekommen, dann wird es in 95% der Browser ansehentlich angezeigt, und im Netscape 4.x funktioniert es wenigstens, ich freue mich inzwischen sogar wenn meine Seiten im Netscape 4 gruselig aussehen, die Leute _können_ die Seite benutzen und die die es nicht tun sind IMHO den Aufwand nicht wert. Das Problem ist nur, das Netscape so langsam mit den Mozilla-Versionen vorankommt, im Netscape 7 wird IMHO Mozilla 1.0.1 oder 1.0.2 verwendet, im 6 noch eine "Beta-Version"(<1), da ist der Mozilla 1.2.1 oder 1.3 Alpha schon erheblich besser! Die Leute haben oft Netscape 6 ausprobiert, aber fanden das keine besondere Verbesserung, da viele Internetseiten damit aufgrund der "Optimierung" auf IE udn NN4 auch nicht richtig funktionieren. Aber diese Seiten werden IMHO immer weniger.Grüße
Andreas
-
-
-
-
-
-
-
ich hab mal ne ganz einfache Frage: wozu <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">, wenn die Seiten genauso gut ohne funktionieren?
Das mag für Dich so aussehen. Tatsache ist aber, daß die Browserhersteller, allen voran Netscape und Microsoft, jahrelang ihr eigenes Süppchen gekocht haben. Verlässliche (d.h. dem Standard entsprechende) Ergebnisse bekommst Du nur mit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
In anderen Modi, die in http://www.hut.fi/~hsivonen/doctype.html mit "Quirks" bezeichnet sind, verhält sich jeder Browser ein wenig anders. Paradebeispiel, weil alle Nase lang auftauchend: Der IE berechnet die Größe von mit CSS formatierten Elementen falsch; erst ab Version 6 im Standardmodus (!) kommt das raus, was auch im Standard beschrieben wurde.
Du kannst also entweder drauf verzichten, lustig rumbasteln, bis es in Deinem Browser funktioniert (alle anderen sind dann egal) und Deine Seiten schließlich mit dem tollen "Optimiert für Onkel Otto 5+" verzieren, oder einfach mit Hilfe von http://validator.w3.org die Standards einhalten - wenn's dann irgendwo hakt, ist es nicht Deine Schuld. Alles eine Frage des Anspruchs.
Gruß,
soenk.ePS: Es soll hier nicht der Eindruck erweckt werden, die Doctype-Angaben sind nur zu dem Zweck erfunden worden, Browser in einen bestimmten Modus zu versetzen. Auf die eigentliche Idee hat Christian schon hingewiesen.