So, schönen guten Tag.
Ich begrüße Sie zur Fortsetzung der Vorlesung angewandte Informatik 2.
Lassen Sie mich heute erstmal damit beginnen, dass ich Ihnen nochmal
kurz hinweise auf die Vorlesungszeiten.
Ich hatte Sie zu Anfang darauf hingewiesen, dass ich nicht immer werde
die Vorlesung halten können.
Wo habe ich das denn jetzt?
Bitte?
Runterscrollen?
Aus irgendeinem Grund.
Lassen Sie mich einmal kurz das hier richtig machen.
Ich kann hier aus irgendeinem Grund nicht scrollen.
Also machen wir das so.
Ich, tut mir leid, ich muss den hier erstmal einmal...
Wenn es irgendwas nicht richtig funktioniert, dann funktioniert alles
nicht richtig.
Jetzt machen wir den nochmal auf.
Und dann kann ich Ihnen gleich das zeigen, was ich wollte.
Genau, jetzt ist er wieder richtig.
Jetzt kann ich Ihnen hier alles zeigen, was erforderlich war.
Nämlich hier unten sind die Termine für die Vorlesung.
Und da sehen Sie, dass wir heute eine Vorlesung haben, hier in diesem
Raum.
Und dann wird die Vorlesung mehrfach nicht in diesem Raum sein.
Auch nicht an diesem Tag.
Nicht am Donnerstag.
Sondern am Montag um 17.30 Uhr.
Das ist ein alter Ausweichtermin.
Und der Hörsaal ist dann der NTI Hörsaal.
Ging halt nicht anders.
Ich bin ein paar Mal nicht da, weil ich aus verschiedenen Gründen
externe Verpflichtungen habe.
Und ich halte die Vorlesung natürlich trotzdem und habe deswegen auf
den Montag verlegt.
Also nächste Vorlesung nach heute ist am Montag, 7.05 Uhr um 17.30 Uhr
im NTI Hörsaal.
Danach sind das die Termine, die angegeben sind.
Dann sind es hier zwei Wochen Pause.
Dann haben wir den 4.06, also dann nach dem 14.05, den 4.06 wieder.
Und dann am Ende nochmal etwas gedrängter.
Ich hätte es gerne anders gedrängt, mehr nach vorne gedrängt, weil man
dann besser mit dem Stoff in den Übungen hinkommt.
Aber es war leider nicht anders möglich.
Tut mir leid.
Also wir haben dann hier 28.
Woche wieder ganz frei und dann am 19.07 die letzte Vorlesung.
So, das als Vorbemerkung.
Jetzt kommen wir zur Vorlesung.
Also letztes Mal haben wir uns beschäftigt mit Daten und Dokumenten.
Ich habe Ihnen angefangen etwas über EDI zu erzählen, was EDI so etwa
ist.
Austausch von Dateien, von Dokumenten in Unternehmensbeziehungen.
Und ich hatte Ihnen kurz gesagt, dass es dafür, für diesen Transfer
von Daten oder von Dokumenten, ein sogenanntes Value-Added-Network
gibt oder solche Value-Added-Networks gibt.
Und ich werde Ihnen dazu noch ein bisschen mehr erzählen heute.
Ich hatte Sie kurz hingewiesen auf diese deutsche EDI-Gesellschaft.
Und das war auch schon alles, weiter kamen wir letztes Mal nicht.
Wir werden uns jetzt ein paar Beispiele anschauen für die Verwendung
von EDI.
Wo wird das tatsächlich eingesetzt?
In der Automobilindustrie ist ein ganz wichtiger Bereich.
Dort gibt es sehr viele Geschäftsbeziehungen zwischen den Herstellern
und den Zulieferern.
Und die müssen häufig sehr kurzfristig ihre Bestellungen abliefern,
Informationen austauschen.
Deswegen läuft das halt im Echtzeitbetrieb.
Und dafür hat man halt Austauschprotokolle entwickelt und auch
unterstützt.
Und hat auch Formate definiert.
Wir haben halt einmal hier das Format des Verbandes der deutschen
Automobilindustrie, VDA.
Und dann gibt es hier ODET, die Abkürzung.
Ist auch eine sinnvolle Abkürzung, die zeige ich Ihnen nachher noch.
Auch da gibt es also Formate, auf die wir später nochmal hinterher
kommen werden.
ODET ist ein Format, das auf europäischer Ebene im Automobilbereich
die Beziehungen zwischen Herstellern und Zulieferern elektronisch
unterstützt.
Also durch digitale Dokumentformate und durch entsprechende Protokolle
unterstützt.
Und das Ganze basiert auf EDI.
Und wie sich das für einen Zulieferer dann auswirken kann, ist hier
ganz kurz angedeutet, dass halt ein Lieferant, oder Quatsch, ein
Hersteller ganz einfach festlegt, nach welchem Format er seine
elektronischen Geschäftsbeziehungen gestalten möchte.
Und wenn ein Zulieferer das nicht kann, dann hat er halt Pech gehabt,
dann ist er nicht mehr im Geschäft.
Ja, so einfach geht das.
Das Problem ist natürlich, wenn ein Zulieferer mit mehreren
Herstellern zu tun hat, die unterschiedliche Formate verwenden, dann
muss er für seine Geschäftsbeziehungen tatsächlich unterschiedliche
Arten von Standards unterstützen, um das hinzukriegen.
Ich hatte Ihnen letztes Mal schon, oder ziemlich zu Anfang, die eine
Seite von Karmann gezeigt, wo drauf stand, welche EDI-Formate
verwendet werden.
Nur mal ganz kurz checken, ob das hier jetzt funktioniert.
Zugriff aufs Netz müsste eigentlich funktionieren.
Und ich sollte eigentlich die Seite hochpoppen, sie tut es nicht, dann
kann ich da direkt drauf gehen.
Hier sehen wir die Seite von Karmann, bei der es halt unterschiedliche
Empfehlungen gibt, für den Geschäftsverkehr, für diese ganzen Arten
hier, Lieferabrufe, Lieferscheine und so weiter, gibt es halt
Standards, VDA-Standards, die einzuhalten sind.
Und hier steht, welche Formate für Datenaustausch verwendet werden.
EDI, Web-EDI, Web-EDI, CAD, das sind also die Formate.
Das heißt, ein Zulieferer muss sich an solche Dinge halten, damit er
tatsächlich im Geschäft mit so einem Hersteller bleiben kann.
Gehen wir zurück auf die Präsentation.
Es gibt speziell für den Automotive-Bereich in Europa ein Value-Added
-Network, das ist European Network Exchange oder auch genannt ENX, für
halt European Network Exchange.
Und auch da, jetzt muss ich schon wieder auf das andere, hier kurz auf
den Link gehen, um Ihnen zu zeigen, was dort zu sehen ist auf so einer
Seite.
Das ist hier ENX und da finden Sie alle möglichen Informationen über
die verschiedenen Beteiligten in verschiedenen Sprachen.
Und Sie können sich also hier anschauen, wer alles beteiligt ist.
Sie sehen, die wesentlichen Automobilfirmen haben sich dort alle
angeschlossen.
Und insofern ist das eine Plattform, in der viele Teilnehmer an dem
Automobilgeschäft beteiligt sind.
Gehen wir darauf wieder zurück.
Ich werde also auf das ENX noch genauer eingehen.
Auf jeden Fall ist es so, dass eine Umstellung auf elektronischen
Datenaustausch natürlich für ein Unternehmen gewisse Umstellungen
erfordert.
Und man sollte natürlich immer sehen, wenn man etwas umstellt auf
einen Geschäftsverkehr, der überwiegend über den Rechner läuft, dann
müssen nicht unbedingt die Geschäftsprozesse im Unternehmen erhalten
bleiben.
Das ist eine Bemerkung, die wird Ihnen in anderen Bereichen auch
häufig erzählt.
Und es ist auch richtig und wichtig, dass man bei einer Umstellung
eines Unternehmens auf digitale Ausführungen von Geschäftsprozessen
natürlich die Geschäftsprozesse auch geeignet umstellen muss auf diese
anderen Möglichkeiten und Randbedingungen.
Jetzt kommen wir hier auf das ENX und da ist halt die Frage, was ist
eigentlich der Vorteil der Nutzung so eines Value Added Networks.
Hier werden also von diesem ENX erstmal Datentransportdienste
bereitgestellt.
Das ist ja das Wesentliche zunächst mal, dass man Informationen
austauschen kann.
Also Datentransportdienste, hier stehen ein paar drin.
Natürlich gehört dazu auch DSL, verschiedene DSL-Standards, ADSL, SDSL
spielen ja auch noch eine Rolle und so weiter.
Ich will auf die Standards gar nicht eingehen, also DSL-Standards mit
verschiedenen Bandbreiten.
Da werden halt Datentransportqualitäten bereitgestellt.
Und Sie können also insbesondere auch garantierte Bandbreiten hier
vereinbaren.
Das kann wichtig sein, wenn man halt sicherstellen muss, dass ein
Austausch von Informationen tatsächlich mit einer gewissen Qualität
erfolgt.
Dafür sind zum Beispiel ATM-Dienste ein sinnvoller Standard, weil man
dort über Qualitätslevel reden kann, Qualitätsstufen bei
Übertragungen.
Die Obergrenze hier 34 Megabit kann man wahrscheinlich erhöhen
mittlerweile.
Das habe ich jetzt nicht nochmal nachgeguckt, was das aktuelle Maximum
ist für die Übertragungsbandbreite.
In der Regel sollte das aber ausreichen.
Also wenn Sie Video-Audio-Transport machen, dann brauchen Sie mehrere
Megabit garantierte Bandbreite.
Wenn Sie 34 Megabit haben, ist das schon sehr viel für eine Leitung
zwischen verschiedenen Partnern.
Also für Videokonferenzen und solche Dinge ist sowas ganz wichtig.
Und man kann eben über so einen ENX nicht nur EDI-Daten austauschen,
sondern noch wesentlich mehr machen.
Hier sind eine ganze Reihe von Leistungen angegeben.
Zugriff aufs Internet, das heißt jemand, der ans ENX angeschlossen
ist, braucht keinen eigenen Internet-Provider.
Der kann einfach über ENX den Zugriff bekommen.
Dann geht es um rechte Verwaltung, also wie kann ich den Zugriff auf
bestimmte Dateien, Dokumente, Informationen verwalten.
Das wird hier gemacht.
E-Mail-Provider ist hier dabei, mit allen möglichen Diensten, die da
eine Rolle spielen.
Dann gibt es ein Branchenportal.
Es gibt sichere E-Mail, also verschlüsselte Kommunikation für
vertrauliche Informationen.
Ein LDAP-Server, Lightweight Directory Access Protocol.
Ein Server, der Nutzerrechte verwaltet.
Über LDAP können Sie die Zugriffsrechte auf bestimmte Systeme in einem
Verzeichnis alle ablegen.
Und ein LDAP-Server, der verwaltet Nutzerrechte in einem größeren
Bereich.
Und dann haben wir hier noch Qualitätsreporting, also Leistungsdaten
von Anschlüssen können hier abgerufen werden.
Wenn Sie mit einem solchen Provider wie ENX einen Vertrag schließen,
dann schließen Sie ein sogenanntes Service Level Agreement, also eine
Dienstgütervereinbarung.
Und dann kann man natürlich auch überprüfen, inwieweit diese
Dienstgüter auch eingehalten werden.
Und auch dieses hier, das letzte Single Sign-On, ist ein wichtiger
Begriff, den Sie in vielen Bereichen finden.
Sie möchten sich nicht für jeden Dienst, den Sie in Anspruch nehmen,
explizit nochmal authentifizieren müssen.
Sie möchten das einmal machen gegenüber diesem ganzen Provider und
dann auf die einzelnen Dienste zugreifen können, entsprechend der
Rechte, die vorher schon vereinbart worden sind, sodass man einen
angenehmen Zugriff hat auf die verschiedenen Dienste.
Was für Dienste werden dort angeboten?
Das sind Dienste in unterschiedlichsten Bereichen, zum Beispiel im
Bereich E-Engineering.
Da hat jemand nicht E hingeschrieben, weil er nicht wusste, ob das
klein oder groß geschrieben wird, das Wort, sondern das bedeutet halt,
dass man sich auf, genau wie bei E-Commerce, auch auf die
digitalisierten Möglichkeiten oder die Möglichkeit der elektronischen
Kommunikation stützt.
Und da können einmal Daten ausgetauscht werden, CAD-Daten, Zeichnungen
und ähnliches.
Sie können Design-Konferenzen machen darüber, dann Sachen wie Product
-Data -Management-Integration.
Stellen Sie sich vor, im Automotive-Bereich haben Sie Lieferketten mit
zig Teilen, die geliefert werden und kombiniert werden müssen, sodass
Sie natürlich dafür sorgen müssen, dass die Dokumentation der
Produkte, die dann am Ende entstehen, auch geeignet aufgebaut wird aus
den verschiedenen Zulieferer-Informationen.
Sowas wird dann im Product-Data-Management gemacht.
Dann kann man hier online zusammenarbeiten, kann Change-Management
simulieren.
Also was passiert, wenn ich in einem Unternehmen bestimmte Dinge
verändere, bestimmte Abläufe verändere.
Welche Auswirkungen hat das auf die charakteristischen Daten dieser
Abläufe.
Was hat das wirtschaftlich für Folgen und so weiter.
E-Supply wäre Supply-Chain-Management über das, worüber wir gerade
gesprochen haben, EDI-Unterstützung.
Dann E-Procurement-Beschaffung kann auch über so ein Value-Added
-Network abgewickelt werden.
Also Service-Teilkatalog, Beschaffung, Auktionen werden hier angeboten
als Dienst von diesem Value-Added-Network.
Oder Application-Service-Provider.
Sie haben hier Verbindungen zu unterschiedlichen Diensten, die von
anderen Stellen angeboten werden.
Sie haben, wie gesagt, E-Mail-Zugang hatte ich vorhin schon erwähnt.
Sie können Daten gemeinsam nutzen, so eine Art Group-Ware-Server für
gemeinsame Arbeit.
Videoconferencing braucht man natürlich, wenn man hier oben stand, CAX
-Conferencing.
Dazu brauchen Sie häufig natürlich auch Videoconferencing-Services.
Sie sehen, ein Value-Added-Network, wie das ENX, bietet sehr viele
Funktionen an, die von den Abonnenten dieses Netzwerkes oder von den
Mitgliedern entsprechend eingesetzt werden können.
Und da das alles in einer speziellen Branche angesiedelt ist, haben
die natürlich auch gleichartige Interessen, sodass die dort
tatsächlich mitarbeiten.
Es sind also mehrere tausend Firmen angeschlossen.
Für Supply Chain, da hatten wir schon kurz drüber gesprochen, braucht
man heutzutage natürlich elektronischen Datenaustausch.
Sie wollen irgendwelche... oder ein Hersteller braucht irgendwelche
Informationen vom Zulieferer, braucht Daten vom Zulieferer.
Und die Abrufe geschehen halt just in time.
Das heißt, in einem sehr kurzen Takt werden dort neue Aufträge
gegeben, die entsprechend auszuführen sind.
Es wird ja nicht mehr ein großes Warenlager gehalten, wo die Waren
alle bereitstehen und nur abgeholt werden müssen, sondern es muss halt
von irgendeiner Firma, die jetzt irgendein Produkt liefert, muss halt
etwas mit dem Fahrzeug tatsächlich jetzt über die Straße hingebracht
werden zu dem Automobilhersteller.
Und das kann sein, dass hier sogar mehrere Stationen überrückt werden
müssen.
Und dann ist natürlich wichtig, dass man diesen Austausch von
Informationen, das Mitteilen der Bestellungen sehr schnell machen kann
mit den entsprechenden Formularen.
Die Lieferungen werden häufig gar nicht beim Zulieferer bestellt,
sondern beim Transporteur.
Das heißt, der Transporteur kümmert sich dann darum, die Waren
tatsächlich zu bekommen.
Und manche Transporteure, also Zulieferer, bauen vor den Toren einer
Firma einfach schon gewisse Zwischenlager auf und liefern dann direkt
aus, wenn etwas gebraucht wird.
Das heißt, hier hat man so eine Art Outsourcing der Lagerverwaltung
von Teilen, die halt in einem Werk gebraucht werden.
Und der Zulieferer, der sieht dann halt, wie der Bestand in dem Lager
ist und wird rechtzeitig, wenn die Lagerbestände unter ein bestimmtes
Niveau gehen, dann wieder weitere Waren anliefern.
Also es geht von dem Hersteller, wenn das hier der Hersteller ist, das
ist der Zulieferer und der Transporteur, das ist der hier, der die
Waren transportiert.
Und damit der ganze Vorgang der Auslieferung schnell geschieht, wird
halt ein elektronischer Lieferschein geschickt an den Hersteller,
sodass der Hersteller bereits bei Ankunft eines LKWs am Werk des
Herstellers die Ware sofort identifizieren kann und richtig
weiterleiten kann.
Wenn man das anders machen würde und der Lastwagenfahrer erst den
Lieferschein abgeben würde, müsste erst entsprechend nachgeschaut
werden, wo das eigentlich hin soll.
Das kann man entsprechend auf elektronische Art und Weise alles vorher
schon geregelt haben und dadurch die Prozesse deutlich beschleunigen.
Also das ist einfach nur sehr kurz gesagt, was ein Vorteil von einer
elektronischen Supply Chain ist.
Ich halte keine Vorlesung über Supply Chain Management hier, sondern
wollte halt nur andeuten, dass man hier sowas braucht, den
elektronischen Lieferschein und natürlich auch eine elektronische
Bestellung und das Ganze im Format entsprechend den EDI
-Vereinbarungen.
EDI -Vereinbarungen in diesem Fall sind halt in Deutschland die VDA
-Empfehlungen, das hatte ich Ihnen auf der Karmann-Seite gesagt.
Das ist in Deutschland der nationale Standard der Automobilindustrie.
Das sind zur Zeit so circa 3000 Unternehmen, die dort Informationen
austauschen nach diesen Standards der VDA und die Arten der Dokumente,
hatte ich Ihnen schon mal aufgelistet, stehen hier nochmal drauf, von
Lieferabrufen über Rechnungen, Zahlungserwiesen bis zu Preisdaten und
ähnlichem.
Also eine ganze Reihe Standarddokumente, die halt alle mit
Empfehlungen versehen sind, ausgearbeitet von entsprechenden
Vertretern der Automobilindustrie, die sich dann auf ein bestimmtes
Format einigen, in dem alle solche Dokumente erstellt werden müssen.
Und wenn man jetzt natürlich sich anguckt, es gibt eigentlich kaum ein
Unternehmen, das nur in Deutschland etwas macht.
Ein deutscher Autohersteller hat natürlich Kontakte mit anderen
Herstellern im europäischen Bereich.
Daimler-Chrysler ist international tätig.
Und insofern reicht es nicht, sich nur auf deutsche Standards zu
beziehen.
Und deswegen gibt es eben auch noch den ODET-Standard und das UN
-Edifakt.
Und das beides gucken wir uns auch ganz kurz an.
Hier nochmal ODET genauer spezifiziert.
Organisation for Data Exchange and Teletransmission in Europe.
Und wenn ich ganz kurz auf die Seite gehe von ODET, dann sehen Sie
hier, es geht darum, Supply Chain Excellence zu erreichen in der
Automobilindustrie.
Und da kann man halt auf die Dienste, die dort angeboten werden,
zugreifen, die ganzen Standards sich angucken und hat damit dann also
die Möglichkeit, im europäischen Bereich in standardisierter Form
Informationen auszutauschen.
Also wann ist das gegründet worden?
In den 80er Jahren von der europäischen Automobilindustrie.
Und standardisiert halt genau diese gleichen Arten von Dokumenten.
Das Problem für das einzelne Unternehmen ist dann, wie Sie z.B.
bei Karmann gesehen haben, jemand der mit Karmann handelt, dort
Geschäftsbeziehungen hat, muss gewisse VDA-Standards einhalten.
Und wer halt mit einem europäischen Hersteller im anderen Land
handelt, der braucht das ODET-Nachrichtenformat.
Wenn jemand im amerikanischen Markt tätig ist, muss er sich an die
ANSI X.12 Formate halten, wieder eine andere Formatierung.
Und dann gibt es für Firmen, die nicht nur im Automotive-Bereich
arbeiten, sondern auch in anderen Bereichen, vielleicht noch
irgendwelche Standards, die sich eher auf die Edifakt-Nachrichten
-Standards beziehen.
Das heißt, jemand der den ganzen Geschäftsverkehr in einem Zulieferer
-Unternehmen organisieren muss, muss für die Formatierung der
elektronischen Dokumente diese unterschiedlichen Standards und
Vereinbarungen für den Austausch von Dokumenten einhalten.
Das ist ein erheblicher Aufwand.
Man muss natürlich versuchen, das zu vereinfachen, aber sowas ist
immer schwierig, weil das wirtschaftliche Interessen sind von
verschiedenen Ländern und man kann nur hoffen, dass das besser gelingt
und dass man vielleicht so eine Überführung von einem Format ins
andere automatisieren kann.
So eine Überführung von einem Format ins andere setzt natürlich
voraus, wenn ich es automatisieren möchte.
Also wenn ich in der Lage wäre, ganz einfach hier Transformatoren zu
schreiben, von dem einen in den anderen Standard, dann wäre es ja
eigentlich egal, dann muss ich halt nur diese Transformatoren
verwenden.
Das dumme ist aber, Sie werden gleich sehen, wie zum Beispiel Edifakt
-Standards beschrieben sind, die haben keine formale Beschreibung.
Wir werden uns die Beschreibung gleich anschauen und das heißt, da
müssen Sie in Handbücher reinschauen und sehen, wie ist dort etwas
definiert und dann können Sie das implementieren in Ihren Systemen.
Das ist ein Problem der informationsverarbeitenden Industrie, dass man
halt sich hier mit unterschiedlichen Standards rumplagen muss.
Die Zukunft liegt sicherlich dabei, das Ganze stärker zu
vereinheitlichen und dabei werden wir später sehen, wird XML
sicherlich eine große Rolle spielen, weil man bei der Verwendung von
XML die formale Beschreibung zur Verfügung hat, die erforderlich ist.
Das war der Automotive-Bereich, es gibt andere Bereiche wie die
Konsumgüterindustrie, da gibt es wieder ein anderes Format, neben dem,
den ich schon genannt hatte, das sogenannte SEDAS-Nachrichtenformat,
Standardregelungen einheitlicher Datenaustauschsysteme.
Sie sehen ein deutlicher deutscher Standard oder deutschsprachiger
Standard seit Ende der 70er Jahre im Einsatz, allerdings nur in
Deutschland und Österreich und auch nur im Lebensmittelbereich für
Bestellungen und Rechnungen angewandt worden.
Inzwischen hat man das alles schon weiterentwickelt, es gab daneben in
Großbritannien etwas, was sich Tradercoms nannte, in Frankreich
GenCod, wir Deluxe-Staaten hatten Icom und das ist natürlich alles
schrecklich in einem europäischen Markt, in dem sie
länderüberschreitend handeln, da können sie nicht mit
unterschiedlichen Standards arbeiten.
Inzwischen haben wir Iancom, das ist der European Article Number
Standard.
Sie kennen alle die Strichcodes auf Produkten, das ist so eine
einheitliche Artikelnummer.
Diese einheitlichen Artikelnummern werden heutzutage weiterentwickelt
und sie wissen, dass man davon redet, Produkte durch RFID-Tags zu
ergänzen.
RFID -Tags sind kleine Sender, die Informationen übertragen können,
sodass man zum Beispiel über die Informationen aus dem RFID-Tag eine
Webseitenadresse bekommt, auf der Informationen über das Produkt
abgespeichert sind.
Das erlaubt einfach ein bisschen mehr flexiblere Informationen, als
man das früher hatte in diesen anderen Standards.
Auf das GS1 Germany gehe ich jetzt nicht ein, da geht es um eine
globale Standards-Webseite, auf der eine ganze Reihe von Standards in
diesem Handelsbereich verwaltet und dokumentiert werden.
Ich werde gleich noch mal mehr eingehen auf das UN-Edifakt.
Ich wollte einfach hiermit andeuten, es gibt eben auch in einem
anderen Handelsbereich, wir hatten Automotive gesehen, Odette und hier
sehen wir jetzt Konsumgüterindustrie, da haben wir wieder andere
Formate, die alle zu Problemen führen können, wenn sie halt so
nebeneinander existieren und man muss sehen, dass man das
vereinheitlicht.
Und ich möchte Ihnen jetzt ein bisschen mehr erzählen über Edifakt.
Edifakt ist halt das, was im internationalen Bereich von den Vereinten
Nationen standardisiert wird.
Das ist also EDI for Administration, Commerce and Transport.
Das sind also große Branchen und Bereiche.
Und jetzt legt also dieses Edifakt fest, welche Datenelemente
innerhalb eines Dokuments, einer Bestellung oder Lieferung oder sowas
ähnlichem notwendig sind, also welche müssen da sein, welche dürfen da
sein, müssen aber nicht unbedingt da sein und welche müssen unter
bestimmten Umständen da sein.
Also unter bestimmten Voraussetzungen müssen einige da sein.
Das legt Edifakt fest, das ist eine Sache.
Und dann wird festgelegt, welche, wir haben also in Edifakt
Nachrichten, da haben wir also irgendwelche Datenelemente und da kann
es Datenelemente geben, die halt wiederholt werden können.
Einige dürfen wiederholt werden, andere nicht.
Andere dürfen in einer bestimmten Anzahl vorhanden sein.
All das wird festgelegt.
Und dann wird festgelegt, was können dort eigentlich für Werte
drinstehen.
Wenn hier irgendein Wert x drinsteht, was ist das für ein Wert?
Welches Format hat der?
Ist das ein alphanumerischer Wert?
Ist das ein reeller Wert oder ein Integerwert?
All solche Dinge.
Und werden also die einzelnen Felder genau definiert.
Und dann gibt es regelmäßige Updates zu diesen Regeln.
Also diese Edifakt Regeln sind internationale Standards und insofern
kann man sich weltweit danach richten.
Es gibt dann wiederum branchenspezifische Untermengen davon,
branchenspezifische Festlegungen.
Alles das, was zum Beispiel in der chemischen Industrie erforderlich
ist, das ist für jemanden, der im Baustoffhandel arbeitet, vielleicht
gar nicht so wichtig.
Und deswegen ist das noch wieder unterteilt.
Sie sehen sogar, Siemens hat einen eigenen Edifaktstandard.
Das heißt, Siemens kann sagen, die Firmen, die mit Siemens handeln,
müssen sich alle im elektronischen Geschäftsverkehr auf genau diesen
Edifaktstandard von Siemens beziehen.
Sie müssen sich danach richten.
Es zeigt einfach, was für ein schwieriger Bereich das ist.
Womit man das zu tun hat, wenn man tatsächlich elektronische
Geschäftsbeziehungen eingehen will.
Diese einzelnen Subsets verstehen sich sogar untereinander nicht, in
dem Sinne, dass sie dort eventuell Datenelemente haben, die in dem
einen Standard vorgesehen sind, im anderen nicht.
Und das heißt, wenn Sie jetzt Ihre Informationen ausgerichtet haben,
Ihre Geschäftsprozesse zum Beispiel auf Editech, Textilwirtschaft,
dann kann es sein, dass Sie dann irgendwelche Bestellungen aus der
chemischen Industrie nicht richtig verstehen können.
Dass da also noch Formattransformationen erforderlich sind.
Ich zeige Ihnen gleich noch Beispiele für die Spezifikationen dieser
einzelnen Standards.
Jetzt gucken wir uns erstmal an, wie die generelle Formatierung so
einer EDI-Nachricht aussieht.
Also eine EDI ist Kommunikation, besteht natürlich darin, dass man
irgendein Dokument schickt von irgendeinem Unternehmen zu irgendeinem
anderen Unternehmen.
Da hatten wir ja schon drüber gesprochen.
Und die Frage ist, wie sieht dieses Dokument eigentlich aus?
Wie ist das strukturiert?
Und das besteht zuunterst aus irgendwelchen Werten, irgendwelchen
Zahlen, Anzahl von irgendwelchen Produkten oder Bezeichnungen von
irgendwelchen Produkten.
Und vielleicht ein Name für eine Schraube, Anzahl von Schrauben,
Größen von solchen Schrauben, sowas kann hier spezifiziert werden.
Und diese Werte stecken in irgendwelchen Datenelementen.
Sie können also entweder ein einzelnes Datenelement haben, oder sie
können ein sogenanntes Gruppendatenelement haben.
Das heißt, sie fassen hier mehrere solche Datenelemente oder
Gruppendatenelemente zu einer Datenelementgruppe zusammen.
Und solche Datenelemente oder Datenelementgruppen, die können dann
wiederum wiederholt werden.
Also wiederholbares Datenelement oder auch eine wiederholbare
Datenelementgruppe.
Die können dann zusammengebaut werden zu einem Segment.
Jetzt sehen Sie hier drin immer so einige Zeichen dazwischen.
Sie haben hier gesehen einen Doppelpunkt.
Ein Doppelpunkt trennt also unterschiedliche Gruppendatenelemente.
Ein Pluszeichen hier trennt Datenelementgruppen voneinander.
Das sind ja wiederholbare Datenelementgruppen.
Und dann sehen Sie, hier haben Sie wieder ein Pluszeichen zwischen
Datenelementgruppe und wiederholbarer Datenelementgruppe.
Da hinten ganz am Ende sehen Sie ein Anführungszeichen.
Hier drin sahen Sie einen Stern.
Der Stern trennte irgendwelche Datenelemente voneinander.
Und dann sehen Sie hier vorne noch einen sogenannten Tag.
Das ist also eine Kopfbezeichnung für so ein Segment.
Das heißt, das Segment wird eingeschlossen durch dieses Tag.
Dieses Tag ist ein Name, der entsprechend aus dem Standard kommt.
Also es kann sein, dass Sie eine Bestellung haben oder ein Name,
Adresse von irgendeinem Kunden oder ähnliches.
Das sind dann solche Tags, die Sie verwenden und welche Werte für die
Tags erlaubt sind.
Das ist dann irgendwo festgelegt in den Standards.
Diese Segmente können auch wieder zusammengebaut werden.
Sind natürlich unterscheidbar durch diese Tag- und Apostroph
-Darstellungen.
Und jetzt haben Sie hier einen Header und einen Trailer für so eine
Folge von Segmenten.
Und das Ganze ist dann eine Nachricht.
Jetzt haben wir also eine Nachricht zusammengebaut aus diesen ganzen
Segmenten.
Und nebenbei beobachten Sie hier, wie sich die Zeiten unterschiedlich
entwickeln auf verschiedenen Uhren.
Da sind einige ganz fasziniert von.
Also ganz kurz, können Sie alle kurz mal raufschauen, damit Sie sehen,
was da passiert.
Anscheinend wird dort die eine Uhr gerade eingestellt.
Die läuft etwas schneller, damit Sie der anderen hinterherkommen, die
die richtige Zeit anzeigt.
Das wird gleich abgeschlossen sein, nehme ich an.
Die eine hatte anscheinend irgendwelche Synchronisationsprobleme.
Jetzt kommen wir zurück zu unseren Nachrichten.
Das ist also eine Nachricht, die verschickt wird.
Und häufig wollen Sie nicht nur eine Nachricht schicken, sondern
mehrere.
Deswegen können Sie mehrere Nachrichten aneinanderreihen.
Dann haben Sie hier so eine Gruppe von Nachrichten, Anfang und Ende
davon charakterisiert.
Wieder getrennt durch solche Apostroph-Zeichen.
Und so eine Gruppe von Nachrichten kann dann zu einer funktionellen
Gruppe zusammengefasst werden.
Oder es können einfach nur die Nachrichten da drin.
Und die werden dann wieder durch einen Header und einen Trailer
gekennzeichnet.
Das macht dann gerade so eine Übertragungsdatei aus.
Und jetzt kann es sein, dass Sie mehrere Dateien übertragen wollen,
nicht nur eine.
Dann hätten Sie halt hier mehrere Dokumente, die nacheinander
verschickt werden.
Aber alle über die gleiche Verbindung.
Das Erstaunliche ist, wenn man jetzt nochmal auf die Zeit guckt, dass
auf einmal die eine Uhr die andere überholt.
Also hier wird gerade die Zeit manipuliert.
Kommen wir zurück zur Vorlesung.
Wir haben jetzt also diese Struktur eines EDI-Dokuments festgestellt.
Wir haben also diese Struktur gesehen.
Bei der Struktur spielt es eine Rolle, welche Elemente
notwendigerweise immer da sein müssen.
Welche optional sind, welche bedingt sind.
Das wird jetzt bei EDI-Fact in diesem Unterstandard festgelegt, was
wird tatsächlich gebraucht.
User Data Segments, also die einzelnen Segmente, hängen natürlich
davon ab, was Sie gerade an Informationen austauschen wollen.
Da werden Sie andere Datensegmente haben, ob Sie jetzt einen
Lieferschein haben oder eine Bestellung oder ähnliches.
Und dann muss eine Nachricht mit einem Header und einem Trailer
versehen sein.
Das ist dieses UNH und UNT, wie es auf der vorigen Folie zu sehen war.
Die müssen also immer da sein.
Dann kann es sein, dass Sie eine Functional Group verwenden.
Für den Fall muss ein Header für die Functional Group da sein.
Auch hier wieder UNG, UNE, Header und Trailer.
Und es muss außerdem ein Interchange Header für den Austausch von
Nachrichten vorhanden sein.
UNB, UNZ, kam auch vor auf der vorigen Folie.
Kennzeichnung, so eine Folge von funktionellen Gruppen oder einfach
nur Nachrichtenfolge.
Und dann gibt es ganz oben drüber noch so ein Service String Advice.
Da können auch irgendwelche weiteren Informationen drin stecken.
Dahinter, also zwischen UNA und UNB, die einfach Informationen sind
für den Dienst, der dort ausgeführt werden muss, um die
Datenübertragung abdeckeln zu können.
Das sind also hier diese Mandatory, Conditional und As Required
Angaben über die Teile so einer EDI Nachricht.
Und jetzt zeige ich Ihnen hier eine Edifact Bestellung, zunächst mal
eine normale Bestellung, wie man sie vielleicht schreiben würde.
Ich habe das hier einfach aus einem Buch rausgenommen, von Deutsch,
über Electronic Commerce.
Und da sehen wir ganz normal, das ist eine Bestellung.
Irgendeine Firma möchte etwas bestellen, bei einem Hersteller.
Und dann sehen wir hier eine bestimmte Bestellnummer, ein
Bestelldatum, Lieferdatum und unten drunter stehen die einzelnen
Positionen, die bestellt werden.
Ist klar, solche Arten Informationen müssen dort drinstehen.
Und wie sieht das aus als Edifact Nachricht?
Da sieht das etwa so aus.
Und Sie sehen, da ist eine gewisse Beziehung da.
Sie sehen hier, da taucht zumindest die Adresse auf von dem Besteller.
Hier taucht die Adresse auf von dem Hersteller.
Und hier unten sehen Sie so etwas mit QTY, also Quantity und Piece und
ähnliches.
Also da steckt da schon alles drin.
Und wenn wir das nochmal genauer angucken.
Hier noch kurz die Bemerkung, das ist also eine Edifact Nachricht.
Also das ist eine Bestellung, das ist der Typ dieser Nachricht.
Und die Definition der einzelnen Elemente richtet sich hier nach der
Version 93a.
Also recht alt, aber ein Standard, der ist halt irgendwo abgelegt und
kann nachgeschaut werden.
Und dann sieht man, was man dort verwenden darf.
Ich zeige Ihnen das gleich noch genauer.
Schauen wir uns nochmal die gleiche Bestellung an.
Was sind dort jetzt für Teile drin?
Wir erkennen einiges wieder.
Also vor dem BGM erkennen wir wieder das UNB.
Und da haben wir hier unten das UNZ.
Korrespondierend dazu.
Da stehen hier so ein paar Sachen.
Da stehen zum Beispiel irgendwelche, die Postleitzahlen finden Sie
hier.
Noch ein paar andere Informationen, die ich jetzt gar nicht weiter
eingehen will.
Dann haben wir hier nochmal einen Header für die Nachricht.
Und das war der Trailer für die Nachricht.
Und dann beginnt die Nachricht mit einem Beginn-Message.
Beginn-Message, Beginn der Nachricht.
Wird also die Nachrichtenart angegeben.
220 und die Bestellnummer 12345.
Dann haben wir eine Datumsangabe.
Das steht hier.
Und zwar haben wir hier einmal das Bestelldatum und das Lieferdatum.
Die sind also angegeben durch diese zwei Zahlen.
137 und 2.
Geben halt an, um was sich das jeweils handelt.
Und dann haben wir hier die Daten in einem bestimmten Format halt
drin.
Dann brauchen wir Dinge wie Name und Adresse.
Name and Address, NAD.
Also alles sinnvolle Tags.
Das sind auch genau diese Tags, die bei den Datensegmenten vorkommen.
Name and Address.
Und dann sehen Sie, wir haben hier einen Buyer.
Der hat irgendeine Adresse.
Und wir haben einen Supplier.
Der hat auch irgendeine Adresse.
Auch dafür sind Formate genau vorgegeben.
Und dann gibt es eine Liste von Bestellungen.
Positionsnummern, Listnumbers.
Da haben wir also Listnummer 1.
Da gibt es eine bestimmte Bestellnummer, Positionsnummer.
Dann haben wir eine Quantity.
Und da steht dann also zwei Stück.
Da unten sehen wir einmal zehn Stück.
Ein Stück.
Also das sind die Bestellungen, die hier drin stehen.
So kann man das alles interpretieren.
Quantity, Mengenangaben zu Positionen und so weiter.
Und Sie können wirklich heilfroh sein, dass Sie nicht händisch mit
solchen IDI-Nachrichten zu tun haben.
Sie sehen, da muss man einiges an Formatierung einfach wissen.
Sie werden vielleicht mal Gelegenheit haben, dass Sie so eine IDI
-Faktbestellung auf einem Blatt Papier finden.
Und dann interpretieren müssen.
Etwa sagen müssen, was da so für Dinge vorkommen.
Fragen dieser Art können vielleicht mal in der Klausur vorkommen.
Aber ich denke, wenn man sich das einmal genauer angeguckt hat, dann
kann man das da rausziehen und weiß in etwa, wie die Struktur ist.
Und was hier so prinzipiell für Informationen drinstehen.
Und jetzt sehen Sie, gibt es halt hier eine Reihe von Standards.
Ich habe hier bei 93a angefangen mit der Auflistung.
Der neueste Standard, der verfügbar ist, ist 06b.
Und ich will jetzt einfach mal auf diese Standard gehen.
Und dann schauen wir doch mal, was es da so gibt.
Das ist also hier unser IDI-EDI-Fakt-Standard.
Und Sie sehen, hier sind immer so die neuesten Nachrichten drin.
Von 2007 gibt es noch keine.
Von 2006 gab es im Dezember die Nachricht, die Version 06b ist jetzt
verfügbar.
Und was sind das für Sachen?
Hier kann man also alle möglichen Informationen abrufen über EDI-Fakt
generell.
Eine Einführung in EDI-Fakt, da sehen Sie die verschiedenen
Definitionen.
Dann sehen Sie hier sogenannte Directories.
Und das sind diese Directories D93a bis D06b.
Und jetzt schauen wir einfach mal rein.
Wir wollen uns das jetzt über HTML anschauen.
Und dann sehen wir hier für die einzelnen Jahre aufgelistet die
verschiedenen Directories, in denen angegeben wird, was eigentlich in
so einer EDI-Nachricht oder EDI-Fakt-Nachricht drinstehen darf.
Schauen wir uns das einfach mal an.
Message-Type-Directory.
Bei Code zum Beispiel.
Da kann man sich unterschiedliche Arten anschauen.
Gehen wir hier mal durch.
Da sehen Sie, geht es um ein Message-Type-Directory.
Und Sie finden dann hier so ein paar Syntax-Informationen zu der Art,
wie das aufgeschrieben wird.
Jetzt schauen wir einfach mal rein.
Hier, da war ich vorhin kurz drin.
Gehen wir da nochmal rein.
Das war Author.
Author stand da.
Wofür steht das?
Schauen wir mal rein, was das eigentlich bedeutet.
Dieses Autor hat mit einem Autor nichts zu tun, sondern das hat zu tun
mit einer Authorization-Message.
Das ist also jetzt die Bezeichnung für eine Nachricht, die verschickt
werden kann.
So eine Nachricht, eine Authorization-Message, die hat natürlich
verschiedene Anwendungen.
Die Nachricht ist in der Dokumentation angegeben, wofür man die
braucht.
Und das war das Inhaltsverzeichnis.
Jetzt geht es los mit Introduction, Functional Definition.
Also, Authorization Message is sent by the ordering customer for payer
or agent on behalf of the ordering customer or by a third party having
authority und so weiter.
Können Sie genau nachlesen, wann man so eine Nachricht einsetzen darf.
Stellen Sie sich vor, Sie müssen Software schreiben, um so etwas zu
unterstützen.
Sie müssen dann hier nachlesen in solchen Dokumenten, unter welchen
Bedingungen man genau diese Nachricht einsetzen darf.
Und das ist so textuell alles schön beschrieben.
So, Field of Application ist angegeben, File Principles, File
References, Terms and Definitions und so weiter.
Und dann sehen Sie, was hier alles so drin steht.
Und jetzt sehen Sie, hier steht etwas darüber, wie die Struktur
eigentlich ist.
Da sehen Sie, da kann drin vorkommen ein Message-Header.
Schauen wir mal darauf.
Oh, Not Found.
Das ist natürlich schlecht.
Das hätte ich nicht erwartet, dass das kommt.
Schauen wir mal hier weiter rein.
Da haben wir weitere Sachen.
Dieser Beginning of Message hatten wir vorhin gerade gesehen.
Beginning of Message taucht ja auch woanders auf.
Also haben wir hier das nächste Dokument.
Beginning of Message.
Wie sieht ein Beginning of Message aus?
Das heißt, wir haben hier die entsprechenden...
Das ist also Document Message Name, Document Name Code, Code List
Identification Code, Code List und so weiter, Document Name.
Verschiedene Sachen.
Schauen wir mal auf sowas drauf.
Was ist das denn hier?
Das nächste Dokument geht auf.
Wir schauen hier wieder nach, was das eigentlich ist.
Document Message Name.
Das ist ein Document Name Code, Code List Identification Code, Code
List Responsible Agency Code, Document Name.
Wenn wir da rein schauen zum Beispiel, kommen wir ins nächste Dokument
rein, und sehen, wie so ein Code List Responsible Agency Code
aussieht.
Und da sehen Sie, das ist hier ein alphanumerischer Wert bis zu drei
Zeichen.
Und hier sind die genauen Werte angegeben.
Da steht jetzt, das kann sein CCC.
Was ist das jetzt?
Hier steht jetzt eins mit vier Zeichen.
Das verstehe ich jetzt nicht.
Tut mir leid.
Hier steht eigentlich bis zu drei, vielleicht ist das null bis drei.
Dann wären es vier maximal.
Also verschiedene Sachen sind hier angegeben.
Die verschiedenen Code-Werte.
Ich will das gar nicht jetzt weiterführen, das würde viel zu lange,
viel zu viel Zeit brauchen.
Ich wollte damit nur darstellen, das ist die Art, wie der Edifakt
-Standard dokumentiert ist.
In solchen Handbüchern.
Und sie haben natürlich auch andere Darstellungen als nur dieses über
HTML.
Aber es ist offensichtlich etwas, was sehr genau spezifiziert ist.
Branchenspezifisch unterschiedlich spezifiziert.
Und außerdem zweimal pro Jahr neue Verzeichnisse mit Änderungen
gegenüber früheren Versionen.
Das heißt, Sie müssen ständig Ihre Software, Sie müssen natürlich
immer sagen, auf welchen Standard Sie sich beziehen.
Und wenn jetzt ein Geschäftspartner sagt, er nimmt jetzt aber einen
neuen Standard, müssen Sie entsprechend in Ihrer Software die ganzen
Veränderungen übernehmen und dort halt einbauen in Ihre
Geschäftsprozesse.
Also das ist sehr umständlich und kommt halt auch aus einer Zeit, wo
man Telex gemacht hat.
Telex-Kommunikation.
Wichtig ist, dass man überhaupt eine Standardisierung hatte von
solchen Informationen.
Also, Ideal und Idefakt standardisieren natürlich die Syntax.
Wie ist das Ganze aufgebaut?
Aber auch die Semantik.
Das ist über diese Handbücher, die ich Ihnen gerade gezeigt habe.
Da wird die Semantik definiert, welche Bedeutung haben bestimmte
Datensegmente, Datenfelder, Nachrichtenbezeichnungen, die in solchen
Ideal -Dokumenten auftauchen.
Also sowohl die Semantik wird spezifiziert, als auch die Syntax, also
der strukturelle Aufbau.
Dass das Ganze sehr aufwendig ist, ist klar.
Zweimal im Jahr werden dort Updates gemacht.
Da sind also ständig Gremien zugange, diese Standards
weiterzuentwickeln und neue Produkte, also einfach neue Technologien
anzupassen.
Und da hatte ich auch schon darauf hingewiesen, dass Sie natürlich
dann entsprechend in allen Unternehmen diese Anpass- und
Transformationsprozesse haben.
Das EDI ist eingeschränkt oder ausgelegt auf die Übertragung
textueller Informationen, nicht auf irgendwelche multimedialen
Informationen oder aktive Informationen wie Applets oder Ähnliches.
Das geht hier wirklich nur um diese Standarddokumente, in denen man
halt nicht mehr braucht als rein textuelle Informationen.
EDI spezifiziert natürlich nicht, wie die Inhalte eines EDI-Dokuments
präsentiert werden oder visualisiert werden.
Das Ganze ist ja darauf aufgebaut, dass Sie im Prinzip das rein
elektronisch verarbeiten.
Und wie das lokal dann in ein Format überführt wird, das dem Vorlieben
des lokalen Unternehmens entspricht, das ist hier eigentlich völlig
irrelevant und deswegen hat EDI damit gar nichts zu tun.
Das ist nur eine Strukturierung von Dokumenten und die soll ein Mensch
eigentlich gar nicht lesen, sondern das soll nur Software lesen.
Programme sollen das durcharbeiten und entsprechend da die
Informationen rausziehen.
Diese Standards sind statisch.
Sie können nicht sagen, ich habe jetzt hier Standard meinetwegen D00A
und möchte aber meine spezielle Variante von Firma XY da noch
einbauen.
Ich habe so ein paar Dinge verändert.
Das geht nicht.
Sie können, wenn Sie sich auf so einen Standard beziehen, nichts
kundenspezifisch verändern.
Es sei denn, Sie hätten wieder einen eigenen Standard geschaffen.
Und auch das ist etwas, was unseren heutigen Anforderungen nicht mehr
entspricht.
Wir erwarten eigentlich, dass man in der Lage ist, Dinge auch
eventuell etwas kundenspezifisch zu personalisieren oder zu
customizen, wie man das in Neudeutsch sagt.
Also diese EDI-Standards sind statisch.
Sie sind festgelegt durch die Referenz auf so ein Directory.
Sie sind nie selbsterklärend.
Sie können also nicht in einem Dokument selbst sagen, wie bestimmte
Teile zu interpretieren sind.
Es gibt Weiterentwicklungen, wie Open EDI, Universal EDI oder Web EDI.
Da versucht man diese Restriktionen aufzubrechen, insbesondere die
Möglichkeiten, das World Wide Web einzusetzen, um EDI ein bisschen
flexibler zu machen.
Aber Sie können sich vorstellen, dass auch das sehr schwierig ist, so
etwas dann allgemein durchzusetzen.
Sie hatten aber gesehen, bei Carmen zum Beispiel war Web EDI auch ein
Teil Technologie, die dort unterstützt wurde.
Und damit bin ich am Ende dieses Abschnitts angekommen und mache jetzt
natürlich weiter mit dem nächsten Kapitel.
Das nächste Kapitel ist dann entsprechend das Kapitel 2.2.
Und hier werden wir uns jetzt mit der nächsten Beschreibungsart
beschäftigen, nämlich mit der Dokumentenbeschreibung im Internet.
Wir sind dann im Internet-Zeitalter und insbesondere, hatte ich ja
auch schon darauf hingewiesen, haben wir das World Wide Web
inzwischen.
Und die Sprache des World Wide Web ist HTML.
Das Ganze, also HTML und auch XML, eine Sprache, von der Sie
wahrscheinlich auch schon gehört haben, das sind Spezialisierungen
oder Varianten einer sehr allgemeinen Sprache, der Standard
Generalized Markup Language.
Das ist eine Sprache, die entwickelt wurde vor einiger Zeit, schon
relativ alt, also über 30 Jahre alt.
Und die hat man entwickelt, weil man in der Lage sein wollte,
Dokumente zu strukturieren in einer systematischen Art und Weise und
auch zu präsentieren.
Das hier hat also etwas damit zu tun, dass man Dokumente strukturieren
und präsentieren will.
Erstmal formal beschreiben.
Wenn man etwas formal beschreiben will, braucht man eine Sprache.
Sie kennen alle die formalen Sprachen.
Über Grammatiken kann man formale Sprachen definieren.
Über sowas ähnliches, Dokumententyp-Definitionen, können Sie die
erlaubte Syntax zur Beschreibung eines Dokumentes festlegen.
Sie können also über eine DTD zum Beispiel festlegen, Dokumententyp
-Buch, Dokumententyp-Zeitschrift, Dokumententyp-Zeitschriftenartikel,
Dokumententyp -Zeitung, Dokumententyp-Artikel innerhalb einer Zeitung
und ähnliches.
Dokumententyp-Poster.
Und da kommt es her.
Das kommt her aus der Druckindustrie, wo man mit elektronischer Art
und Weise Dokumente beschreiben und drucken wollte.
Dafür ist es eingebaut oder eingeführt worden.
Man macht das so, dass man bei dieser Journalized Mark-Up-Language
sogenannte Mark-Ups verwendet.
Und Mark-Ups sind solche Marken, mit denen man Inhalte des Dokuments
einschließt, um sie zu charakterisieren.
Das kann also sein wie Haus oder Adresse oder Stadt oder Straße oder
Name oder ähnliches.
Das sind solche Marken, die einen bestimmten Teil, hier steht also
irgendwas dazwischen, irgendein Text, und der wird durch diese Marke,
Anfangsmarke, Endmarke, hervorgehoben, strukturiert.
Das ist eine Möglichkeit, dass ich sage, ich habe hier eine Marke und
dazwischen steht irgendein Text.
Es kann aber auch sein, dass man eine Marke verwendet und dann
dahinter eine Reihe von Attributen.
Ich zeige Ihnen das gleich noch beim Beispiel.
Mit diesen Attributen will man bestimmte Dinge dann spezifizieren.
Ich könnte zum Beispiel eine Marke haben, die Postleitzahl angibt.
Und das Attribut könnte sein, dass ich irgendein länderspezifisch die
angeben möchte, dass dort steht Deutschland oder Kanadisch oder
Australische Postleitzahl oder was was immer.
Dann hätte man über das Attribut den Inhalt, der dann dahinter kommt,
noch genauer spezifiziert.
Jetzt sehen Sie bei dieser Marke mit Attributen etwas ganz besonderes.
Da steht am Ende dieser Schrägstrich.
Und der Schrägstrich stand hier oben zu Beginn der Endmarke.
Das, was hier in der zweiten Zeile steht, wäre also nur eine Marke,
die nur Attribute hat und gar keinen weiteren Inhalt.
Die endet dann gleich damit.
Das heißt, da ist das Wesentliche die Definition dieser Attributwerte
durch Text 1, Text 2 und so weiter.
Das Ganze dient dazu, das Dokument zu strukturieren.
Jetzt kommt der nächste Bestandteil.
Ich sagte, es geht um Dokumentenstruktur und um
Dokumentenpräsentation.
Und zur Präsentation und zur Visualisierung, etwas was im Druckbereich
natürlich das Entscheidende ist, braucht man auch eine entsprechende
Sprache.
Dafür hat man die Document Style Semantics and Specification Language
oder DSSL.
Das wird also hier als DSSL ausgesprochen.
Das ist diese Document Style Semantics and Specification Language, die
darstellt, wie ein Dokument visualisiert werden soll.
In welchem Medium auch immer.
Druckindustrie ist klar, wie soll das gedruckt werden.
Welcher Farbe, welcher Zeichensgröße und so weiter.
Und ich kann, wenn ich also jetzt eine solche DTD habe, ein Dokument
mir einfach hernehmen und kann das parsen.
Entsprechend der DTD, entsprechend dieser Grammatik, die Struktur
feststellen.
Feststellen, ob das Dokument der Struktur entspricht.
Ob es also ein Element der durch die DTD definierten formalen Sprache
ist.
Kann also auch formale Übereinstimmung mit der Definition dieses Typs
überprüfen.
Und dann kann ich entsprechend die Regeln der DSSL anwenden, um das
Dokument zu präsentieren.
Ich gebe Ihnen ein ganz kleines Beispiel, auch wieder nach März.
Ich definiere eine sogenannte Mini-HTML.
Da haben wir also erstmal eine DTD.
Dokumententypdefinition.
Und da sehen Sie einige Dinge, die dort drinstehen.
Ein DOCTYPE wird definiert.
Der DOCTYPE heißt hier Mini-HTML.
Und dann finden Sie in dieser Mini-HTML mehrere Elemente.
Jedes Element wird durch Markups gekennzeichnet.
Und Sie sehen also wie hier, wir haben da ein Element Mini-HTML.
Also das Element Mini-HTML.
Und dieses Element Mini-HTML kann, da sehen Sie hier so zwei Kringel.
Zu denen sage ich gleich was.
Das bestehen aus einer Folge.
Da steht der Stern.
Stern ist die Standardbezeichnung in Syntax-Definitionen für
Iterationen.
Also beliebige Folgen von irgendeinem H1 und P. Der senkrechte Strich
ist international der Standard für eine Oder-Bezeichnung.
Also eine Disjunktion.
Entweder H1 oder P und das Ganze beliebig oft.
Und dann steht hier zweimal so ein O.
O ist eine Abkürzung für optional.
Was kann hier optional sein?
Wir haben ja immer solche Markups.
Irgendwas dazwischen und dann haben wir so ein Endetag.
Also Anfangstag, Endetag.
Und diese hier können entweder optional sein oder nicht optional.
Also verpflichtend.
Und das sind die beiden Möglichkeiten.
Hier oben ist angedeutet, dass man auf den Einschluss eines Dokumentes
durch in diesem Fall Mini-HTML verzichten könnte.
Ist optional.
Und zwar beides.
Anfang und Ende ist optional.
Sie können das beliebig kombinieren.
Das nächste bei dem Element H1 oder P. Da ist beides verpflichtend.
Und H1 oder P, diese beiden Elemente bestehen aus wieder drei
verschiedenen Möglichkeiten, die iteriert sein können.
Das erste wäre eine Folge von Zeichen.
Und zwar Past-Character-Data.
Past-Character-Data heißt, es wird das, was im Text steht.
Ich habe also hier dann irgendein Text, hier steht irgendwas und dann
könnte es sein, dass da drin wieder die Zeichen Klammer auf und
Klammer zu drin vorkommen.
Dann würde beim Past-Character-Data das, was zwischen Anfangstag und
Endtag steht gepast werden und sobald hier Syntax-Elemente auftauchen
wie Klammer auf, Klammer zu, werden sie interpretiert als SGML
-Elemente und entsprechend behandelt.
Alternative wäre einfach nur Character-Data.
Dann würden solche Zeichen nicht als solche Elemente der Sprache oder
solche Syntax-Elemente interpretiert werden.
Und dann kann es sein, dass hier ein Element hervorkommt oder ein
Element betont und die sind hier unten drunter definiert, die beiden
Elemente hervor oder betont, brauchen also beide ein Anfangs- und
Endtag und zwischen diesem Anfangs- und Endtag darf dann jeweils
wieder Past-Character-Data stehen.
Das heißt, das ist eine Folge von irgendwelchen Zeichen.
Jetzt haben wir eine ganze HTML definiert, hier drunter war es nochmal
beschrieben.
Hier steht nur ein wichtiger Punkt, wir haben also ein HTML-Dokument,
ein Wurzel-Element, das ist also diese Mini-HTML.
Das Element beschreibt das Dokument und darunter können dann
irgendwelche weiteren Elemente folgen, wie eben h1 oder p und das
können auch beliebige Komponenten sein.
Jetzt steht hier ein Beispiel, da haben wir also, obwohl sie optional
sind, Anfangstag und Endtag hingeschrieben und Sie sehen jetzt hier
einmal ein H1-Element, da steht jetzt einfach, dies ist eine
Überschrift, dann haben wir hier ein p-Element, dies ist ein
beliebiger Text und hier sehen Sie, in dem p-Element steht jetzt hier
ein hervorelement und dafür ist natürlich wichtig, dass das p-Element
Past -Character-Data enthält.
Wenn das nicht Past-Character-Data enthalten würde, sondern nur
einfach Character-Data, dann würde das gar nicht als ein Element
interpretiert werden, sondern nur als Text.
Und hier unten drunter sehen Sie noch ein Beispiel, wo das Element
betont nochmal wieder vorkommt.
Ganz einfaches Beispiel.
Sie haben solche HTML, also komplexere HTML-Dokumente, alle schon
gesehen und sehen hier einfach nur einen ganz einfachen Dokumententyp,
der sehr ähnliche Dinge verwendet, wie Sie die aus HTML kennen, aber
das ist ja wirklich eine ganz einfache Sprache, die strukturiert halt
irgendein Dokument.
So, das ist nur Syntax.
Semantik ist natürlich nicht festgelegt.
Sie können zwischen dieses H1 und End Tag H1 beliebige Sachen
hinschreiben.
Da steht jetzt dieses eine Überschrift.
Sie könnten da auch drei Seiten Text hinschreiben.
Das würde nichts ändern.
Es steht ja nur in der Dokumententyp-Definition, welche Markups Sie
verwenden dürfen.
Da steht nicht, welchen Inhalt der Text oder welche Bedeutung der Text
zwischen diesen Markups, zwischen diesen Tags haben muss.
Also es ist hier nur die Syntax definiert.
Die Semantik bleibt hier draußen vor.
Die wird so ein bisschen, wenn Sie sich anschauen, wie man solche Tags
definiert, gerade wenn wir uns später XML anschauen, da versucht man
das halt durch den Namen dieser Tags, dieser Elemente anzudeuten, was
man als Text erwartet.
Und Sie können, es gibt auch Strukturierungsmöglichkeiten, mit denen
man so ein bisschen mehr über die Semantik machen kann.
Da kann man Datentypen definieren und ähnliches.
Aber das sind deutlich fortgeschrittene Sachen.
Das ist hier alles noch nicht mit drin.
Wir haben hiermit insbesondere auch nicht festgelegt, wie dieses
Dokument präsentiert wird.
Ich habe Dinge hier so intuitiv reingeschrieben, hervor und betont.
Das steht dann hervorgehoben oder fettgedruckt.
Das ist aber hier auf dieser Seite nur Syntax.
Was dann konkret passiert bei der Präsentation, steht hier nicht.
Das muss durch ein weiteres Dokument festgelegt werden.
Und das geschieht durch den DISSEL, durch ein sogenanntes Style Sheet.
Da muss ich also jetzt wieder festlegen, wie jetzt mein Style Sheet
aussehen soll.
Hier steht, es wird ein Format verwendet von einer Style Sheet DTD.
Da wird also das Format für Style Sheets festgelegt.
Und das weitere, was hier folgt, ist so ein Style Sheet.
Und dieses Style Sheet wird festgelegt, wie die Elemente eines
Dokumententyps jetzt zu visualisieren sind.
Also, das Element Mini-HTML soll dargestellt werden als eine Simple
Page Sequence.
Es muss natürlich bekannt sein, was diese Bezeichnung Make Simple Page
Sequence bedeutet.
Das ist die Semantik der DISSEL, über die ich hier gar nicht viel
sage.
Das ist hier intuitiv klar, wie das zu interpretieren ist.
Sonst muss man natürlich wissen, was damit dann passiert.
Dann haben wir hier das Element H1.
Und da steht bei H1, soll also ein Paragraf geschrieben werden.
Mit einem bestimmten Zeichensatz, der hier als Areal angegeben ist.
Dann ist hier eine bestimmte Art der Darstellung angegeben, nämlich
Fettdruck, Bold.
Eine Größe der Zeichen, 20 Punkt.
Abstand zwischen den einzelnen Zeilen, 22 Punkt.
Dann haben wir einen gewissen Abstand vor so einem Paragrafen von 15
Punkt, dahinter nochmal 10 Punkt.
Dann soll das Ganze zentriert werden.
Und hier muss noch angegeben werden, dass dieser Paragraf fest
verbunden sein soll mit dem nächsten Paragraf.
Üblicherweise ist so etwas eine Überschrift.
H1 ist also eine Überschrift.
Jetzt haben wir festgelegt, wie das was dort zwischen einem H1 Anfangs
- und Endetag steht, tatsächlich repräsentiert werden soll, wenn es
gedruckt oder auf dem Bildschirm dargestellt wird.
Dann haben wir noch ein weiteres Element, nämlich den Paragrafen P.
Oder das Element P. Das wird interpretiert wieder als ein Paragraf.
Mit dem gleichen Zeichensatz, aber Sie sehen eine andere Größe.
Auch kein Fettdruck, sondern normaler Druck.
Auch hier angegeben, Line Spacing, Space Before, Start Indent.
Also Sie haben hier einen eingerückten Absatz, etwas in der Art.
6 Punkt und außerdem noch eine Angabe, wie die Anordnung sein soll.
Also das sind so typische Beschreibungen, wie ein Text tatsächlich
darzustellen oder wie Elemente darzustellen sind.
Es waren noch mehr Sachen drin.
Es war noch da drin, das hervor und das betont diese beiden Elemente.
Und da sehen Sie, wenn eine Textfolge mit hervoreingeschlossen ist,
dann soll eine Folge von Zeichen daraus entstehen.
Und diese Folge von Zeichen soll in Italik dargestellt werden, also
Kursiv.
Italik heißt ja normalerweise Kursiv.
Und wenn dort betont steht, dann soll der Text zwischen dem Anfangs
und Ende Tag im Fettdruck angegeben werden.
Damit haben wir das also auch jetzt angegeben und dann haben wir im
Prinzip jetzt also so ein Dokument strukturiert und präsentiert.
Wir wissen, wie man das machen kann.
Man hat SGML, das sagte ich schon, eingesetzt vor allen Dingen für den
Druckbereich, um Dokumente systematisch drucken zu können mit
elektronischen Hilfsmitteln.
Und dann hat Tim Berners-Lee halt SGML verwendet, um einen speziellen
Dokumententyp zu definieren, nämlich den HTML-Dokumententyp.
Und er hat ein entsprechendes Style-Sheet dazu definiert, fest damit
verbunden.
Und damit hat man mit HTML üblicherweise eine feste Präsentationsart
für die Inhalte.
Sie schreiben also ein HTML-Dokument und Sie wissen, da sind
Standardpräsentationen mit verbunden, auf die Sie bauen können.
Also durch DTD und Style-Sheet sind die Semantik der Marken und die
Regeln für die Präsentation der Dokumente fest definiert.
Warum die Semantik der Marken?
Naja, wenn Sie eine Marke P haben, dann ist die Bedeutung, dass ein
Paragraf gemacht wird.
Das heißt nicht, dass Sie etwas über die Semantik der textuellen
Inhalte zwischen Anfangs- und Endetags wissen.
Das ist völlig offen.
Die Semantik bei HTML bezieht sich immer nur auf die Präsentation der
Dokumente.
Wie wird ein Dokument strukturiert, um ein sinnvolles Layout auf einer
Webseite tatsächlich zu bekommen.
Und es gibt relativ einfache Werkzeuge, um HTML-Dokumente
darzustellen.
Da ich diesen Standard habe für Struktur und Präsentation, kann ich
auch ein Werkzeug schreiben, das genau ausgerichtet ist auf diese
Arten von Dokumenten.
Und dann kann alles in einer einheitlichen Form interpretiert werden.
Es muss halt, wenn hier sowas steht, wie so ein Element hervor, soll
eine Folge von Zeichen sein inklusiv.
Das kann jeder Browser entsprechend darstellen.
Und damit haben wir eben diese Browser oder die Darsteller für HTML
-Dokumente.
Hier ist ein ganz kurzes Beispiel.
Wenn man auf den Link geht, kriegt man dieses Bild geliefert.
Das können Sie jetzt nicht sehen, da muss ich doch einmal ganz kurz
auf das Dokument gehen.
Dann sollte man eigentlich genau, da sehen Sie jetzt in größer, das
was da steht.
Dieses Dokument, da sehen Sie hier oben, erstmal sehen Sie
verschiedenste Dinge in so einem Browser.
Da sehen Sie hier oben, in der obersten Zeile steht Forschungsgruppe
effiziente Algorithmen.
Das muss ja, das hängt mit dem Dokument zusammen, das gerade angezeigt
wird.
Dann haben wir hier, das alles dazwischen ist ja nur Menüzeilen von
dem Browser.
Und dann steht hier etwas inklusiv, Institut für angewandte
Informatik, formale Beschreibungsverfahren.
Dann sehen Sie hier einen unterstrichenen Teil.
Wenn ich da raufklicke, wissen Sie, dann komme ich auf eine andere
Seite, die damit verlinkt war.
Dann steht hier Universität Karlsruhe, TH Karlsruhe, Germany.
Und ein Bild ist angezeichnet, darunter steht Forschungsgruppe
effiziente Algorithmen und Mitarbeiter.
Sie sehen unterschiedliche Schrifttypen und eine bestimmte Anordnung
der Texte auf dieser Seite.
Wie hängt das jetzt zusammen mit unserem HTML?
Das ist also das Dokument, das dort zu sehen ist, das präsentiert
wurde.
Und dahinter steckt dieser Code, den man sich übrigens auch natürlich
anschauen kann.
Ich hoffe, das wissen Sie ja, ich nehme an, dass Sie das auch alle
wissen, dass Sie bei Ansicht natürlich immer auf den Seitenquelltext
gehen können.
Und da haben Sie genau die HTML-Beschreibung dieser Seite.
Also wenn Sie lernen wollen, wie man interessante Seiten macht,
schauen Sie sich einfach an, wie diese Seiten strukturiert sind.
Da finden Sie zig Beispiele, die haben Sie überall zur Verfügung.
Da können Sie sehen, wie solche Seiten tatsächlich definiert wurden.
So, zurück.
Wir wollten auf die Vorlesungsfolie zurück.
Und da sehen wir also jetzt hier, was dort steht.
Wir haben hier vorne ein HTML, dann steht dort ein Head, also ein
Kopfbereich.
Und da steht jetzt ein Titel in diesem Kopfbereich, das ist also hier
unser Kopfbereich.
Head und End-Marke von Head, also die End-Marke zu HTML steht hier
unten, da ist das End-HTML.
Dann haben wir hier drin einen Title.
Und dieser Title, Forschungsgruppe Effiziente Algorithmen, stand oben
in der Leiste, in der obersten Leiste dieses Fensters, das gezeigt
wurde.
Das war dieser Title.
Dann steht hier etwas, was farbig hervorgehoben ist, ein Kommentar.
Sie können an jeder Stelle in so einem HTML-Dokument Kommentare
einblenden, oder einfügen.
Ganz wichtig, insbesondere kann man eben hier solche
Änderungsdokumentationen machen, dass man sich anschaut, wer hat da
alles mal dran rumgewirbelt an diesen Texten.
Und dann hat man so ein bisschen den Eindruck, wie das Ganze
entstanden ist.
Etwas, was man halt händisch hier in dem Fall machen muss.
Das kann auch automatisch gemacht werden, wann die letzte Änderung
durchgeführt wurde, aber das ist hier halt manuell gemacht über den
Kommentar.
Dann ist der Kopf zu Ende und es kommt der Rumpf.
Und der Rumpf, sehen Sie hier, enthält also einige Dinge.
Er enthält eine Adresse.
Und bei der Adresse, offensichtlich wird die Adresse in diesem Fall
kursiv dargestellt.
Was ist das denn hier?
Das ist jetzt eben etwas, was mit den verschiedenen Zeichen zu tun
hat, die in den verschiedenen Zeichensätzen vorkommen, sprachlich,
national unterschiedlich.
Wir haben halt die Umlaute.
Und hier steht also eine Referenz.
Das ist dieses ampersand oder dieses und-Zeichen.
Eine Referenz auf ein bestimmtes Zeichen.
Und das Zeichen, das hier referenziert wird, ist U-Umlaut.
U-U-UML soll also angeben U-Umlaut.
Das heißt, der Browser bekommt dadurch mitgeteilt, er muss hier ein U
-Umlaut hinschreiben.
Und das Semikolon ist also das Ende dieser Referenz.
Also für die normalen moderne Browser sind auch in der Lage, ein U
-Umlaut als Text tatsächlich zu interpretieren, aber nicht jeder
Browser.
Und eigentlich formal muss man das so machen, wie es hier steht.
Also eigentlich können die nur die einfachen Zeichen erkennen.
Und dann steht hier diese Adresse.
Und dann sehen Sie hier etwas, was mit einem Tag beginnt.
Tag A geht auf und dann sehen Sie ein Attribut.
Ein Attribut href gleich und da steht dann etwas in Anführungszeichen.
Was Sie hier sehen ist ein Link, eine URL.
Und das ist das, was im Prinzip aufgerufen wird, wenn Sie auf dieses
AIFB unterstrichen, auch farbig anders gekennzeichnet.
Das AIFB ist hier angegeben, das heißt so ein Link wird immer in einer
bestimmten Farbe dargestellt.
Das ist durch HTML nicht explizit angegeben, sondern implizit wird das
hier so gemacht.
Und dann ist dieser Link beendet.
Also das Anfangstag hat ein Attribut href, das war der Link, die URL.
Die Bezeichnung des Links ist der Text zwischen Anfangs- und Endetag.
Und dann wird dieses Element beendet.
Und damit ist auch schon die Adresse beendet.
Und dann kommt hier ein Break.
Einfach nur brrrr, ein einfacher Tag, der sagt, ich gehe auf die
nächste Zeile.
Line Break.
Und da steht jetzt einfach Universität Karlsruhe, TH, Karlsruhe,
Germany.
Keine weitere Formatierung angegeben, es steht einfach nur Text da
drin.
Das ist das, was hier oben steht.
Und danach kommt ein P, also ein P-Element, was als Paragraf
interpretiert werden soll.
Heißt auch, ich gehe in eine neue Zeile, aber eventuell heißt das noch
ein bisschen mehr, als nur ein Break zu machen.
Insbesondere brauchen Sie hier ein Anfangsp- und ein Endp, wenn Sie da
oben ein Anfangs-Endetag hatten.
Und in diesem Paragrafen, der hier dargestellt werden soll, wird ein
Bild dargestellt.
Ein Image.
Und die Quelle für dieses Bild ist eine Datei, die an der gleichen
Stelle liegen muss, im gleichen Verzeichnis, wie das HTML-Dokument,
das aufgerufen wurde.
Wird also auf eine Datei verwiesen, die hier im gleichen Verzeichnis
stehen muss.
FALG, Gruppe 2006, Punkt JPEG.
Und außerdem steht hier noch, dass der Rand dicke 0 haben soll, also
es soll ohne Rand abgedruckt werden.
Und es soll 300 Pixel hoch sein und 400 Pixel breit.
Hätte ich hier 500 Pixel breit geschrieben, wäre es halt etwas
gequetscht worden.
Kann man also beliebig formatieren, so ein Bild, auf diese Art und
Weise.
Etwas fehlt hier übrigens, für eine qualitativ akzeptable HTML-Seite.
Es fehlt hier die Angabe, was dort eigentlich steht auf diesem Bild.
Es müsste hier ein sogenanntes Alt-Attribut noch drinstehen, für
Alternativ -Inhaltsangabe.
Und da muss ein Text stehen, der sagt, was auf diesem Bild gezeigt
wird.
Das braucht man für Browser, die keine Bilder anzeigen können.
Oder zum Beispiel für Blinde, die gar nicht sehen können, was auf dem
Bild drauf ist.
Und die brauchen Informationen darüber, was eigentlich hier
dargestellt werden soll.
Das kommt noch etwas später darauf ein, dass man solche Regeln
beachten muss.
Und dann kommt hinter diesen Paragraphen etwas mit einem H1-Element,
Forschungsgruppe Effiziente Algorithmen, und ein H4-Element
Mitarbeiter.
Und Sie sehen in der Darstellung, diese beiden H-Elemente werden sehr
unterschiedlich repräsentiert oder präsentiert.
Nämlich in unterschiedlichen Zeichengrößen.
Das sind also unterschiedliche Überschrifttypen.
H1, die größte Überschrift, bis runter, ich weiß gar nicht, ob das bis
H6 oder sowas runter geht.
Jedenfalls verschiedene Stufen.
Und Sie sehen, H4 ist schon relativ klein.
Da steht das Mitarbeiter relativ klein drin.
Und das ist schon das Ende dieser ganz einfachen HTML-Seite.
Das also nur dazu, wie so ein HTML-Dokument normalerweise aussieht.
Jetzt schauen wir uns das ein bisschen allgemeiner an.
Die allgemeine Struktur war so, dass wir ein HTML-Anfangs-Ende-Tag
haben.
Wir haben immer so einen Kopfbereich, in dem ein Titel-Tag vorkommen
muss.
Und wir haben dann ein Body-Tag.
Ich verzichte jetzt darauf, zu zeigen, wie das dann aussieht.
Wenn Sie so ein HTML-Dokument schreiben, das aufrufen, dann erscheint
oben auf dem Browser-Fenster genau dieser Text.
Und im Rumpf, auf dem Darstellungsfeld, erscheint dann genau dieser
Text im Fenster des Browsers.
Das ist also dann ein einfaches HTML-Dokument.
Wenn Sie etwas über HTML lernen wollen, können Sie sich natürlich ein
bisschen anschauen, was ich jetzt hier in der Vorlesung erzähle.
Aber ich behaupte niemals, dass Sie aufgrund der Informationen in der
Vorlesung schon vollständig informiert sind darüber, welche
Möglichkeiten Sie in HTML haben.
Das kann gar nicht Aufgabe einer Vorlesung sein, Ihnen all diese
Möglichkeiten zu erzählen.
Ich kann Sie auf ein paar prinzipielle Dinge hinweisen.
Ansonsten brauchen Sie irgendwelche Tutorials.
Und Self-HTML ist ein sehr gutes Tutorial, sehr ausführlich, mit
vielen Beispielen versehen, wo die einzelnen Elemente dargestellt
werden, erläutert werden, an Beispielen erläutert.
Sie können also sich anschauen, wie ein bestimmter HTML-Text, ein
bestimmtes Element von HTML sich darstellt, wenn Sie das im Browser
aufrufen.
So ein paar Dinge will ich Ihnen aber schon noch erzählen.
Wie strukturiert man ein HTML-Dokument?
So ein HTML-Dokument soll ja, also nachher möchte ich gerne in meinem
Browser -Fenster irgendetwas sehen.
Da soll ein Text sein.
Aber wo soll denn der Text hin?
Und ich kann bestimmte Bereiche definieren.
Ich kann also Bereiche definieren, die ich im Prinzip beliebig
platzieren kann auf dem Browser-Fenster.
Normalerweise finden Sie ja bei einer Webseite Informationen verteilt
über das ganze Fenster.
Und an welcher Stelle die Information erscheint, wird festgelegt,
dadurch, dass Sie erstmal solche Bereiche definieren.
Jeder solche Bereich ist ein Bereich, der beschrieben werden soll oder
eingeschlossen werden soll durch diese Div-Tags.
Das ist ein allgemeiner Dokumentenbereich oder ein Container für
Inhalte.
Und Sie können über die Präsentation, über ein Style-Sheet, genau
angeben, an welcher Stelle so ein Bereich stehen soll, wo der
auftauchen soll.
Wenn Sie das nicht machen, wenn Sie nicht sagen, wo der Inhalt so
eines Div-Bereiches stehen soll, dann werden einfach alle Div-Bereiche
untereinander angeordnet.
Und Sie haben eine Darstellung, die vernünftig aussieht.
Oder einigermaßen vernünftig, aber eben nicht strukturiert.
Und dann gibt es halt hier, diese Header hatte ich schon gesagt, es
gibt ein Paragraf, ein Absatz.
Es gibt Listen, Sie können also ungeordnete Listen machen, Sie können
geordnete Listen machen, also ungeordnete Liste, das wäre sowas mit
solche Kringel oder Sie können vielleicht auch irgendwelche Kasten
-Informationen da machen oder einfach nur ein Strich.
Solche unterschiedlichen Listen können Sie definieren.
Das sind ungeordnete Listen.
Da können Sie aber auch geordnete Listen machen, 1, 2, 3 oder A, B, C
oder ähnliches.
Solche Listen definieren und Sie können natürlich auch dann die
einzelnen Listen-Elemente angeben.
Also Sie können über Attribute angeben, was zum Beispiel bei einer
ungeordneten Liste das Zeichen sein soll, also dieses Ballett, was das
sein soll.
Soll das jetzt ein Kreis sein, soll das ein Punkt sein oder Strich
oder bei den geordneten Listen, was soll das?
Soll das numerisch oder alphabetisch sein?
Sie können Bilder angeben, hatten Sie auch schon gesehen.
Das war hier, das ist wieder so ein Beispiel für ein Bild.
Und hier sehen Sie das mit dem Attribut alt für Alternate.
Hier steht also etwas als Beschreibung.
Das ist nicht die Beschreibung, die man da hinschreiben würde.
Wenn Sie hinschreiben, hier sollte eigentlich ein Bild stehen, gibt
das nicht die Information, die gebraucht wird.
Normalerweise schreibt man dorthin etwas zur Erklärung des Inhaltes,
der auf dem Bild gezeigt wird.
Und Sie können halt die Breite und Höhe genau spezifizieren.
Dann können Sie Tabellen angeben und hier sehen Sie gleich einen
dicken roten Satz.
Tabellen braucht man, um irgendwelche Dinge zu spezifizieren.
Sie haben hier meinetwegen irgendeine Tabelle, haben hier irgendwelche
alphabetischen Sachen und wollen hier meinetwegen Zahlen angeben.
5, 2, 3, 1, das wäre eine Tabelle.
Da hätten Sie eingeteilt in irgendwelche Zeilen, irgendwelche
Informationen, irgendwelche Werte werden dorthin geschrieben, das ist
eine Tabelle.
Manche Autoren von Webseiten verwenden aber Tabellen, um einfach die
Inhalte auf einer Webseite anzuordnen.
Dafür gibt es aber das Diff-Element.
Und die Tabellen sind dafür nicht da.
Und deswegen verstoßen Tabellen gegen Anforderungen der
Barrierefreiheit, wann immer sie eingesetzt werden, um nur das Layout
zu strukturieren.
Tabellen sollte man selbstverständlich einsetzen, um Inhalte sinnvoll
so tabellarisch aufzuführen, sofern es sinnvoll ist, sofern es vom
Inhalt her Sinn macht.
Ansonsten aber nicht.
Dann gibt es ein Strukturierungselement, das sich Frame nennt.
Ein Frame wäre etwas, wo Sie, also wenn das das Fenster ist, wir haben
hier einen breiten Bildschirm, dann können Sie auch ein Frameset
definieren.
Dieser Frameset in diesem Beispiel würde sagen, 30% etwa ist ein
linker Frame, der erste Frame, dann ist ein Frame der Breite 300
Pixel, und da steht ein Stern, dritter Frame ist der ganze Rest.
So kann ich also Bereiche in einem Bildschirm aufteilen, und ich kann
die einzelnen Bereiche mit eigenen Inhalten versehen, indem ich zum
Beispiel sage, für ein Frame nehme ich jetzt ein spezielles HTML
-Dokument, das wird dann dort in dem Frame dargestellt.
Wenn Sie sowas machen, wenn Sie also auf eine Frameseite gehen, dann
werden Sie feststellen, Sie gehen auf irgendeinen Link, Sie gehen
also, hier steht man wegen irgendeinem Link, Sie gehen darauf, und
das, was bei Ihrem Browser oben in der URL-Zeile steht, verändert sich
überhaupt nicht.
Es verändert sich nur der Inhalt eines Frames, und es ist durch die
URL oben in der Browser-Zeile gar nicht registriert worden.
Das heißt, das ist schwierig, zum Beispiel einen Bookmark zu legen,
also einen Merker auf so einen Link, weil das gar nicht richtig
registriert wird.
Und solche Frames verstoßen aus diesem Grund und auch aus einer Reihe
anderer Gründe gegen auch wieder Anforderungen der Barrierefreiheit.
Sie sind ein durchaus interessantes Gestaltungsmerkmal oder eine
interessante Gestaltungsmöglichkeit für Webseiten, aber sie verstoßen
gegen Prinzipien der Barrierefreiheit, also Barrierefreiheit für
Menschen, die in irgendeiner Weise behindert sind, und deswegen werden
Frames eigentlich nicht mehr eingesetzt.
Sollte man gar nicht verwenden.
Sie werden trotzdem feststellen, dass Sie viele Webseiten finden, die
Frames enthalten.
Und hier sehen Sie also, nochmal kurz zum Beispiel, dass man hier also
irgendwelche Frames hat, DIV-Bereiche, wo Inhalte drin stehen, hier
unten haben wir eine Tabelle, in der irgendetwas stehen kann, und nur
zur Strukturierung hier Überschriften, unterschiedlichen Größen,
Paragraphen, und hier haben Sie Listen-Element, nur angedeutet, wie
das aussehen kann.
An dieser Stelle werden wir dann am Montag weitermachen, wie gesagt,
nächste Vorlesung Montag, 17.30 Uhr.
Jetzt können Sie sich die Zeit aussuchen, die eine zeigt gerade kurz
nach eins, die andere Uhr zeigt schon wieder 20 vor zwölf, aber ich
gehe davon aus, dass die 13 Uhr richtig ist.
Vielen Dank für heute, das war's.