XML / XSD

Original von Chris

Original von Amin Negm-Awad
In diesem Falle meinte ich allerdings einen anderen Christian.

Aber als gemeinsames Projekt wäre das doch in der Tat schön.

Wie? Ich bin der einzig wahre Christian

Du bist der einzig wahre Christian und dann gibt es noch einen einzig wahren Christian.

Der andere einzig wahre Christian hat sich allerdings schon mit der Modellbeschreibung von Core Data beschäftigt.

Original von Chris
Hab leider zuwenig Zeit mich zu beteiligen, Lust schon.

Geht mir derzeit auch so. Und es sieht so aus, als ob das bis zum Ende des Jahres so bliebe. Danach wäre ich dabei.

Original von Chris

Original von macmoonshine
Wie wäre es mit einem Open-Source-Projektchen zum Thema XML-Verarbeitung?

Dann aber LGPL oder ähnliche Lizenzen.

Ja, ich wollte LGPL machen:

Verwendung des unmodifizierten Codes ohne Beschränkungen, modifizierter Code muss veröffentlicht werden.

Alex

Original von Amin Negm-Awad
Ich muss durch die Abstraktionsbrille schauen, da man das ursprüngliche Problem in Objective-C anders lösen würde. Eine Lösung über Klassengeneratoren hat doch erhebliche Nachteile in Bezug auf die Flexibilität und entspräche wohl auch nicht den dynamischen Möglichkeiten von Objective-C. Wenn man es machen will, will man es doch richtig machen. – Und nicht so wie in Java

Die Abstraktionsbrille finde ich auch sehr schick. Ich meinte aber etwas Anderes: Es als Core-Data-Implementierung zu sehen! Die Idee finde ich super. XML Data Binding zu implementieren ist aber schon ordentlich Arbeit.

In Java gibt es mit JAXB und den XMLBeans mindestens zwei sehr unterschiedliche Ansätze für XML-Data-Binding. Zumindest JAXB kommt dabei sogar auch ohne Schema aus. Den Ansatz von XML-Beans (obwohl über Code-Generator) finde ich aber nicht schlecht, weil die XML-Beans auf dem DOM-Baum des XML-Dokuments rumrödeln. Dadurch kannst Du so lustige Sachen machen, wie XPath auf den Beans einsetzen oder beliebiges XML einmischen.

Es ist wahrscheinlich am sinnvollsten, die XML-Data-Binding-Implementierung vom Core-Data-Adapter zu trennen.

Ich glaube, dass wir aneinander vorbeireden. Mir geht es um die XSD, also die Definition. Hieraus baue ich mir eine Core-Data-Modellbeschreibung. Das Lesen von konkreten Dokumenten dürfte doch jetzt schon ohne Probleme mit NSXMLParser funktionieren. Oder unterstützt der kein XSD?

Nein, NSXMLParser kann gar keine Validation, das kann nur NSXMLDocument (oder libxml2)

EDIT: LESEN kannst Du die Dokumente natürlich mit NSXMLParser. Aber nicht validieren.

Alex

Original von below
Nein, NSXMLParser kann gar keine Validation, das kann nur NSXMLDocument (oder libxml2)

EDIT: LESEN kannst Du die Dokumente natürlich mit NSXMLParser. Aber nicht validieren.

Alex

Davon sprach ich ja auch.

Original von Amin Negm-AwadDavon sprach ich ja auch.

Ich bezog mich auf Deine Frage:

Original von Amin Negm-AwadOder unterstützt der kein XSD?

Da dachte ich, Du wolltest validieren.

Gruss

Alex

Original von below

Original von Amin Negm-AwadDavon sprach ich ja auch.

Ich bezog mich auf Deine Frage:

Original von Amin Negm-AwadOder unterstützt der kein XSD?

Da dachte ich, Du wolltest validieren.

Gruss

Alex

Das hat ja nichts damit zu tun, ob ich eine DTD oder ein XSD verwende.

Original von Amin Negm-Awad
Das hat ja nichts damit zu tun, ob ich eine DTD oder ein XSD verwende.

Jetzt reden wir irgenwie aneinander vorbei. Validieren kannst Du nur, wenn Du eine DTD oder XSD hast. Und das geht nicht mit NSXMLParser, nur mit NSXMLDocument (oder libxml2).

Natürlich kannst Du xml Dateien, die über eine DTD oder XSD definiert sind, mit NSXMLParser lesen.

Im Fall von xsd Dateien kannst Du dann sogar diese Dateien selbst mit NSXMLParser lesen -- DTDs nicht.

Alle Klarheiten beseitigt?

Alex

Original von below

Original von Amin Negm-Awad
Das hat ja nichts damit zu tun, ob ich eine DTD oder ein XSD verwende.

Jetzt reden wir irgenwie aneinander vorbei.

Nein

Original von Amin Negm-Awad
Validieren kannst Du nur, wenn Du eine DTD oder XSD hast.

Eben, deshalb schrieb ich ja auch: "Das hat ja nichts damit zu tun, ob ich eine DTD oder ein XSD verwende."

Original von below
Und das geht nicht mit NSXMLParser, nur mit NSXMLDocument (oder libxml2).

Natürlich kannst Du xml Dateien, die über eine DTD oder XSD definiert sind, mit NSXMLParser lesen.

Das Lesen von konkreten Dokumenten dürfte doch jetzt schon ohne Probleme mit NSXMLParser funktionieren. Oder unterstützt der kein XSD?

Original von Amin Negm-Awad
Im Fall von xsd Dateien kannst Du dann sogar diese Dateien selbst mit NSXMLParser lesen -- DTDs nicht.

Auch das ist mir klar, hat mit dem Thema aber nichts zu tun.

Original von Amin Negm-Awad
Alle Klarheiten beseitigt?

Mir war nichts unklar.

Original von Amin Negm-Awad
Das Lesen von konkreten Dokumenten dürfte doch jetzt schon ohne Probleme mit NSXMLParser funktionieren. Oder unterstützt der kein XSD?

Jetzt verstehe ich Deine Frage überhaupt nicht mehr.

Ja, das Lesen von konkreten Dokumenten funktioniert ohne Probleme mit NSXMLParser.
Und ja, NSXMLParser unterstützt kein XSD.

Alex

Original von Amin Negm-Awad
Ich glaube, dass wir aneinander vorbeireden. Mir geht es um die XSD, also die Definition. Hieraus baue ich mir eine Core-Data-Modellbeschreibung. Das Lesen von konkreten Dokumenten dürfte doch jetzt schon ohne Probleme mit NSXMLParser funktionieren. Oder unterstützt der kein XSD?

Das kann mensch vielleicht sogar schon fast mit einer XSL-Transformation machen. Du musst dann natürlich die konkreten Daten noch mit Core-Data lesen & schreiben können. Andererseits muss auch überlegt werden wie Core-Data- auf XML-Schema-Features und umgekehrt abgebildet werden.

Platt gesagt ist ein XML-Schema-basierter Core-Data-Adapter ein SAX-Parser (oder DOM-Interpreter) der über das Schema-Dokument definiert wird. Dazu kann mensch dann auch XML Data Binding sagen.

Da wahrscheinlich aber Core-Data nicht alle Features von XML-Schema ausnutzt, wäre es sicherlich nicht unklug, ein XML-Data-Binding-Framework zu schreiben und den Core-Data-Adapter draufzusetzen. Der Core-Data-SQLite-Adapter setzt ja wahrscheinlich auch auf dem SQLite-Treiber auf.

Wie bereits gesagt:

a) Es geht mit darum, eine Core-Data-Modellbeschreibung auf einer XSD zu machen, nicht darum, ein Core-Data-Model aus einem XML zu machen.

b) XML-Parser gibt es bereits. Und wie Alex ganz richtig sagte, kann man sogar einfach einen NSXMLParser nehmen, das eine XSD eine XML ist.

Original von Amin Negm-Awad
a) Es geht mit darum, eine Core-Data-Modellbeschreibung auf einer XSD zu machen, nicht darum, ein Core-Data-Model aus einem XML zu machen.

Das ist schon klar. Ich möchte auch kein Core-Data-Modell aus beliebigen XML-Dateien generieren. Um aus einer XSD ein Core-Data-Modell zu erzeugen sollte mal ernsthaft geprüft werden, ob nicht sogar eine XSL-Transformation ausreicht oder zumindest eine XSLT mit SAX-Filtern.

Original von Amin Negm-Awad
b) XML-Parser gibt es bereits. Und wie Alex ganz richtig sagte, kann man sogar einfach einen NSXMLParser nehmen, das eine XSD eine XML ist.

Genauso kannst Du einfach lex und yacc nehmen, um einen Objective-C-Compiler zu schreiben

Eine XSD beschreibt ja die Syntax einer Klasse von XML-Dokumenten. Der Core-Data-Adapter soll ja ungefähr so funktionieren: Du gibst dem Ding eine XSD und damit weiß es, wie es beliebige XML-Dokumente, die der XSD entsprechen, öffnen kann. Dazu muss der Core-Data-Adapter die XSD "verstehen".

Kann der XML-Core-Data-Adapter von Apple mit beliebigen XML-Formaten umgehen oder nur mit XML-Dokumenten im Property-List-Format?

Original von macmoonshine

Original von Amin Negm-Awad
a) Es geht mit darum, eine Core-Data-Modellbeschreibung auf einer XSD zu machen, nicht darum, ein Core-Data-Model aus einem XML zu machen.

Das ist schon klar.

Tatsächlich?

Original von macmoonshine
Ich möchte auch kein Core-Data-Modell aus beliebigen XML-Dateien generieren. Um aus einer XSD ein Core-Data-Modell zu erzeugen sollte mal ernsthaft geprüft werden, ob nicht sogar eine XSL-Transformation ausreicht oder zumindest eine XSLT mit SAX-Filtern.

Was denn jetzt? Ein Model oder eine Modelbeschreibung?

Original von macmoonshine

Original von Amin Negm-Awad
b) XML-Parser gibt es bereits. Und wie Alex ganz richtig sagte, kann man sogar einfach einen NSXMLParser nehmen, das eine XSD eine XML ist.

Genauso kannst Du einfach lex und yacc nehmen, um einen Objective-C-Compiler zu schreiben

Ich weiß nicht, welches Problem du mit NSXMLParser hast. Das Ding existiert bereits.

Original von macmoonshine
Eine XSD beschreibt ja die Syntax einer Klasse von XML-Dokumenten.

Nein, es beschreibt das Schema, also die Struktur.

Original von macmoonshine
Der Core-Data-Adapter soll ja ungefähr so funktionieren: Du gibst dem Ding eine XSD und damit weiß es, wie es beliebige XML-Dokumente, die der XSD entsprechen, öffnen kann.

Nein, du gibst dem Adapter ein XSD und es erzeugt daraus ein Core-Data-Modelbeschreibung.
Damit dürften 98 % erschlagen sein

Dazu muss der Core-Data-Adapter die XSD "verstehen".

Nein, der XSD-Adapter muss ein XSD verstehen und überhaupt kein Dokument (vom XSD abgesehen). Es erzeugt eine Modelbeschreibung.

Original von macmoonshine
Kann der XML-Core-Data-Adapter von Apple mit beliebigen XML-Formaten umgehen oder nur mit XML-Dokumenten im Property-List-Format?

Jedenfalls nicht definiert.

Deshalb muss – eine ganz andere Aufgabe – ein Store-Type existieren – dazu benötigt man keinen Adapter, der aufgrund der Core-Data-Modellbeschreibung das XML liest.

Du vermischst hier ständig zwei Baustellen.

Original von Amin Negm-Awad
Tatsächlich?

Tatsächlich! Du hast sicherlich eine wesentlich größere Erfahrung als ich mit Core-Data und vielleicht verwende ich nicht immer den korrekten Terminus. Ich habe aber schon recht viel mit XML-Schema, XML-Data-Bindings, SAX-Parsern und XSLTs gearbeitet und eine Vorstellung davon, wie es mit Core-Data laufen könnte. Vielleicht können wir ja mal diese Schleife verlassen und versuchen ein "Big Picture" zu malen.

Original von Amin Negm-Awad
Was denn jetzt? Ein Model oder eine Modelbeschreibung?

Wahrscheinlich ist Modellbeschreibung richtig. Ich bin mir aber nicht sicher. In EOF wären es die Model-Dateien, die der EOModeler erzeugt.

Original von Amin Negm-Awad
Ich weiß nicht, welches Problem du mit NSXMLParser hast. Das Ding existiert bereits.

Gar keins! Wir können den gerne verwenden. Kein Problem! Aber mit dem Ding kannst Du "nur" eine XML-Datei in SAX-Events umwandeln genauso wie lex "Worte" in Token umwandelt. Ich will bestimmt kein lex oder yacc zum XML-parsen einsetzen.

Original von Amin Negm-Awad
Nein, es beschreibt das Schema, also die Struktur.

Mit Syntax habe ich die XML-Struktur gemeint.

Original von Amin Negm-Awad

Original von macmoonshine
Der Core-Data-Adapter soll ja ungefähr so funktionieren: Du gibst dem Ding eine XSD und damit weiß es, wie es beliebige XML-Dokumente, die der XSD entsprechen, öffnen kann.

Nein, du gibst dem Adapter ein XSD und es erzeugt daraus ein Core-Data-Modelbeschreibung.
Damit dürften 98 % erschlagen sein.

Mit dem "Nein" suggerierst Du einen Widerspruch der m. E. hier gar nicht gegeben ist. Ob der Adapter mit Modellbeschreibungen, die aus XSDs generiert werden, oder direkt mit XSDs, die intern konvertiert werden, finde ich erstmal nicht so relevant. Wahrscheinlich sind beide Wege möglich.

Original von Amin Negm-Awad
Jedenfalls nicht definiert.

Deshalb muss – eine ganz andere Aufgabe – ein Store-Type existieren – dazu benötigt man keinen Adapter, der aufgrund der Core-Data-Modellbeschreibung das XML liest.

Du vermischst hier ständig zwei Baustellen.

Wie geschrieben: Wahrscheinlich verwende ich nicht immer den richtigen Begriff. Ich denke, wir haben zwei verschiedene "Bilder" im Kopf, die wahrscheinlich gar nicht so unterschiedlich sind

Ich würde mich über zwei Sachen freuen: 1. Dein Bild kennenzulernen und 2. das Du nicht immer "Nein" schreibst, wenn ich versuche, mein Bild zu erklären.

Original von macmoonshine

Original von Amin Negm-Awad
Tatsächlich?

Tatsächlich! Du hast sicherlich eine wesentlich größere Erfahrung als ich mit Core-Data und vielleicht verwende ich nicht immer den korrekten Terminus. Ich habe aber schon recht viel mit XML-Schema, XML-Data-Bindings, SAX-Parsern und XSLTs gearbeitet und eine Vorstellung davon, wie es mit Core-Data laufen könnte. Vielleicht können wir ja mal diese Schleife verlassen und versuchen ein "Big Picture" zu malen.

Original von Amin Negm-Awad
Was denn jetzt? Ein Model oder eine Modelbeschreibung?

Wahrscheinlich ist Modellbeschreibung richtig. Ich bin mir aber nicht sicher. In EOF wären es die Model-Dateien, die der EOModeler erzeugt.

Ich habe das nun wirklich über mehrere Beiträge hervorgehoben.

Aber es geht in der Sache darum, dass es gedanklich zu trennen gilt:

Die Erzeugung der Modelbeschreibung kann ja vorab erfolgen. Man muss nicht jedes Mal aus dem XSD eine Modelbeschreibung erzeugen. Das Lesen eines konkreten Dokumentes kann dann bereits auf dieses vorhandene Model aufsetzen. Mir scheint, dass nur dies überhaupt SAX-Style zulässt, da IIRC Core Data nicht freundlich wird, wenn man Entitäten verändert, nachdem man bereits Instanzen erzeugt hat.

Original von macmoonshine

Original von Amin Negm-Awad
Ich weiß nicht, welches Problem du mit NSXMLParser hast. Das Ding existiert bereits.

Gar keins! Wir können den gerne verwenden. Kein Problem! Aber mit dem Ding kannst Du "nur" eine XML-Datei in SAX-Events umwandeln genauso wie lex "Worte" in Token umwandelt. Ich will bestimmt kein lex oder yacc zum XML-parsen einsetzen.

Mir war schon klar, dass du das überzogen meintest. Ich verstand das nur nicht.
Klar, ich will das SAX-Style machen. Gerade wenn man nicht nur Core-Data unterstützen will, sondern sich gleich ganz seine eigenen Klassen zur Laufzeit zusammenbaut, wäre das ja auch ein Ansatz für das iPhone.

Den sollte man sich nicht mit DOM kaputtmachen.

Original von macmoonshine

Original von Amin Negm-Awad
Nein, es beschreibt das Schema, also die Struktur.

Mit Syntax habe ich die XML-Struktur gemeint.

Original von Amin Negm-Awad

Original von macmoonshine
Der Core-Data-Adapter soll ja ungefähr so funktionieren: Du gibst dem Ding eine XSD und damit weiß es, wie es beliebige XML-Dokumente, die der XSD entsprechen, öffnen kann.

Nein, du gibst dem Adapter ein XSD und es erzeugt daraus ein Core-Data-Modelbeschreibung.
Damit dürften 98 % erschlagen sein.

Mit dem "Nein" suggerierst Du einen Widerspruch der m. E. hier gar nicht gegeben ist. Ob der Adapter mit Modellbeschreibungen, die aus XSDs generiert werden, oder direkt mit XSDs, die intern konvertiert werden, finde ich erstmal nicht so relevant. Wahrscheinlich sind beide Wege möglich.

Ich meinte das nicht als Widerspruch, sondern als Trennung der beiden zu lösenden Probleme.

Original von macmoonshine

Original von Amin Negm-Awad
Jedenfalls nicht definiert.

Deshalb muss – eine ganz andere Aufgabe – ein Store-Type existieren – dazu benötigt man keinen Adapter, der aufgrund der Core-Data-Modellbeschreibung das XML liest.

Der Store-Typ ist für das Lesen einzelne Dokumente. Hier ging es noch um die Erzeugung der Modelbeschreibung. Dazu bietet Core Data AFAIK gar keine API an außer einfach der API, mit der man eben zu Fuß Modelle machen kann.

Wenn man also vom NSXMLParser einen Knoten meldet, muss man gleichzeitig die Modelbeschreibung anlegen. Das hat aber nichts mit dem Laden einzelner Dokumente zu tun.

Wenn man es ohne Core-Data macht, dann müssen eben entsprechende Klassen zur Laufzeit erzeugt werden. Bei dem Lesen der Dokumente werden die dann eben instantiert.

Original von macmoonshine

Original von Amin Negm-Awad
Du vermischst hier ständig zwei Baustellen.

Wie geschrieben: Wahrscheinlich verwende ich nicht immer den richtigen Begriff. Ich denke, wir haben zwei verschiedene "Bilder" im Kopf, die wahrscheinlich gar nicht so unterschiedlich sind

Ich würde mich über zwei Sachen freuen: 1. Dein Bild kennenzulernen und 2. das Du nicht immer "Nein" schreibst, wenn ich versuche, mein Bild zu erklären.

Hi Amin,

so langsam verstehe ich, worauf Du hinauswillst. Ich versuche mal, das, was in meinem Kopf so rumschwirrt*, in ein Bildchen zu packen.

Viele Grüße
Clemens

* Nein, keine Sorge nicht ALLES

Inzwischen denke ich schon darüber nach, ob man nicht CD außen vor lassen sollte und einfach sich Klassen zur Laufzeit erzeugt, die passen. Meist sind die Dokumente ja eher klein.

Ich verfolge ein wenig Eure Diskussion. Da ich im XML-Umfeld recht aktiv bin würde mich jetzt interessieren, was aus Eurer Sicht "kleines" Dokument bedeutet, bzw. ab wann aus Deiner Sicht CD sinnvoll wäre.
Klar, das Szenario in dem XML eingesetzt wird, bestimmt häufig die zu erwartende Größe. Bei einem Web-Service, der Börsendaten abfragt, bekommt man andere Datenmengen zusammen als wenn man z.B. Datenaustausch betreibt und ein Flugzeug versenden möchte.

Viele Grüße,
Erik