Re: Highspeed parsen - aber wie?

Wolfgang Zitzelsberger schrieb:

Da ich meinen Horizont bez. Parserbau etwas erweitern will, wird
definitiv eine manuelle Lösung angestrebt. Auch eine Vereinfachung wäre
denkbar, soll aber erst mal keine Rolle spielen. Die Implementierung
sollte außerdem möglichst kompakt sein - kann man eine Aussage darüber
treffen welche Größe der generierter Code ungefähr hätte? Wünschenswert
wäre < 50KB.

Das sollte man hinbekommen - der Code mag dann aber nicht wirklich schön
sein. Ich hatte hier mal vor einiger Zeit einen fast vollständigen
Smalltalk-Parser gepostet - das waren wenigen K für's class file.

Wie sieht es mit der Weiterverarbeitung der geparsten Daten aus. Wird
dazu eine Lib/API benötigt?

IMHO die falsche Frage. Die geparsten Daten wären der CSS-Quelltext und
den kannst du nach dem Parsen wegschmeißen. Deine Frage ist glaube ich,
ob man im Parser dann eine Repräsentation der CSS-Syntax, einen
sogenannten abstrakten Syntaxbaum (engl. AST) erzeugen sollte. Die
Antwort ist: Das kommt darauf an. Sowas zu machen, erlaubt eine
einfachere Weiterverarbeitung, kostet aber (ein kleines bisschen) Platz
und Zeit. Wenn du z.B. nur die Regeln zählen willst oder gucken, welche
Styles für "a" festgelegt wurden, was für Klassen es gibt oder ob das
CSS überhaupt syntaktisch korrekt ist, reicht es in der Regel, direkt
beim Parsen die Aktionen durchzuführen.

Vergleiche das am besten mit SAX und DOM. SAX sagt dir Bescheid, wenn
der Parser Elemente und Attribute findet, DOM baut einen AST.

--
Stefan Matthias Aust
.

Relevant Pages

  • Re: Problem reading large amount data from xml tag
    ... SAX is expected to divide text up wherever's convenient for the parser's input buffers, since SAX was theoretically intended to be a thin layer between the parser and application. ... But DOM Level 1 Core's description of Text nodes, reiterated in Level 2 and Level 3, says "When a document is first made available via the DOM, there is only one Text node for each block of text." ... So it's surprising, disappointing, and annoying that Mozilla isn't honoring that expectation. ...
    (comp.text.xml)
  • Re: XmlTextreader versus DOM
    ... I've heard them referred to as "DOM" and "SAX". ... DOM is, generally speaking, the easiest way in which to deal with XML ... "SAX" (named after the original parser, I think) parsers read one XML ...
    (microsoft.public.dotnet.languages.vc)
  • Re: XmlTextreader versus DOM
    ... I've heard them referred to as "DOM" and "SAX". ... DOM is, generally speaking, the easiest way in which to deal with XML ... "SAX" (named after the original parser, I think) parsers read one XML ...
    (microsoft.public.dotnet.xml)
  • Re: XML PARSER
    ... First DOM and SAX are really the only way to go and they are competing ... DOM basically builds a tree of the XML and allows you to ... What you us for a parser is really a matter of what environment you plan to ...
    (microsoft.public.dotnet.general)
  • Re: passing xml documents
    ... integration and various other XML integration tasks. ... My parser is far from SOA quality. ... DOM when the docs got to a few megs in size. ... Yes Shirley get everywhere doesn't she. ...
    (comp.databases.pick)