[PHP] Reg Exp (ms word filter)

[LuCarD]

Ik ben bezig om een ms word filter aan het maken. Aangezien word nogal brakke(overbodige) html maakt.

Nu wil ik dus met regular expressions, deze heb ik al.

PHP:

<?
$word_input = preg_replace ("/(<P\s)(\w+)([^>]*>)/e", "'<P>'", $word_input);  // FILTERT ALLE <P +> eruit en maakt er <P> van.
$word_input = preg_replace ("/(<\?)(\w+)([^>]*>)/e", "''", $word_input);  // Filtert <? +> wat XML dingen

//
// Deze komen niet voor in stukje onderaan
// <o:p>  en </o:p> (wat zijn  dat voor tags????
//
$word_input = preg_replace ("/(<[a-zA-Z]:)(\w+)([^>]*>)/e", "''", $word_input); // Er staat tags in zoals <o:p> na filter niet meer
$word_input = preg_replace ("/(<\/[a-zA-Z]:)(\w+)([^>]*>)/e", "''", $word_input); // Er staat tags in zoals </o:p> na filter niet meer
?>

Nu wil ik nog een filter maken die alle "class=+" dingen eruit gooit, die classes staan toch niet in een style sheet, dus nutteloos. Maar dat wil niet helemaal lukken.

Verder zou iemand kunnen kijken of boven staande makkelijker kan? Het werkt maar of het goed is, geen idee

En zijn er nog mensen die meer dingen er uit zouden filteren? ideeen? tips?

Voor de mensen die geen Word hebben (lucky bastards), hier heb je een klein gedeelte word html.

code:

<P class=MsoNormal style="MARGIN: 0cm 0cm 6pt; mso-layout-grid-align: none"><SPAN style="FONT-SIZE: 9.5pt; mso-bidi-font-size: 10.0pt">This guide builds on the configuration achieved in </SPAN><SPAN style="COLOR: black; mso-bidi-font-family: Arial">Upgrading NT to Windows 2000 Active Directory<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 6pt">The administration tools are installed by default on all Windows 2000-based domain controllers. On Windows 2000-based stand-alone servers or workstations, the Active Directory service administration tools are optional and can be installed from the Optional Windows 2000 components package.</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 6pt"><A name=_Toc438716861>&nbsp;<o:p></o:p></A></P>
<H2 style="MARGIN: 14pt 0cm 0pt"><SPAN style="mso-bookmark: _Toc438716861"><A name=_Toc474139825></A><A name=_Toc475104160><SPAN style="mso-bookmark: _Toc474139825"><FONT face="Arial Black" size=2>Scenario Tasks</FONT></SPAN></A></SPAN></H2>
<P class=MsoNormal style="MARGIN: 0cm 0cm 6pt">You perform the following tasks in this walkthrough.</P>
<TABLE style="BORDER-RIGHT: medium none; BORDER-TOP: medium none; MARGIN-LEFT: 6.15pt; BORDER-LEFT: medium none; BORDER-BOTTOM: medium none; BORDER-COLLAPSE: collapse; mso-border-top-alt: solid gray 1.5pt; mso-padding-alt: 0cm 5.4pt 0cm 5.4pt; mso-table-layout-alt: fixed; mso-border-bottom-alt: solid gray 1.5pt" cellSpacing=0 cellPadding=0 border=1>
<TBODY>
<TR style="HEIGHT: 15pt">
<TD style="BORDER-RIGHT: #c0c0c0; PADDING-RIGHT: 5.4pt; BORDER-TOP: gray 1.5pt solid; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: #c0c0c0; WIDTH: 159.45pt; PADDING-TOP: 0cm; BORDER-BOTTOM: gray 0.75pt solid; HEIGHT: 15pt; BACKGROUND-COLOR: transparent" vAlign=top width=213>
<P class=MsoNormal style="MARGIN: 0cm 0cm 6pt"><SPAN style="FONT-SIZE: 8pt; mso-bidi-font-size: 10.0pt">Setup and Management Tasks<o:p></o:p></SPAN></P></TD>
<TD style="BORDER-RIGHT: #c0c0c0; PADDING-RIGHT: 5.4pt; BORDER-TOP: gray 1.5pt solid; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: #c0c0c0; WIDTH: 198pt; PADDING-TOP: 0cm; BORDER-BOTTOM: gray 0.75pt solid; HEIGHT: 15pt; BACKGROUND-COLOR: transparent" vAlign=top width=264>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Administering Active Directory including-Organizational Units, Delegation of Administration, user accounts (create, delete, rename, finding users), password policy, account lockout </FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Administering groups including create, add users </FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Administering file resources including create shared folders and assigning permission.</FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Administering print resources including create shared printers and assigning permissions.</FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Administering Web resources including configuring authentication, permissions and default documents, and creating a virtual directory.</FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>Monitor event logs including how to set audit triggers and monitor audit logs to maintain a record of security and user-related network events.</FONT></P>
<P class=TableBullet style="MARGIN: 2pt 0cm 0pt 18pt"><SPAN style="FONT-FAMILY: Symbol"><FONT size=2>·</FONT><SPAN style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN></SPAN><FONT size=2>End user tasks-requesting a certificate, creating a Web folder, presenting ad certificate for authentication.</FONT></P></TD></TR></TBODY></TABLE>

[drm]

waarom gebruik je de "e" modifier in je regex

code:

/.../e

Je gebruikt toch geen functieaanroep in het 2e argument van preg_replace?

PHP:

<?
$word_input = preg_replace ( "/<td([^>]*+)>(.*)+<\/td>/g", "<td>\\3</td>" );
?>

* drm is niet zo'n held in regexen

[LuCarD]

Op donderdag 15 november 2001 16:32 schreef drm het volgende:
waarom gebruik je de "e" modifier in je regex

Het stond in me voorbeeld die ik had van een regex.... Wie ben ik om hem dan weg te halen?

* drm is niet zo'n held in regexen

Nee ik ben een held

[drm]

* drm vond dit wel een aardige link om wat beter op de hoogte te komen van regexen

mail2sms regex guide

Beetje puzzelen met dat in de rechterhand lukt het wel denk ik. Daar ben ik iig een heel end mee gekomen (voor emailadresvalidatie etc).

suc6 neway

[tomato]

LuCarD: Nu wil ik nog een filter maken die alle "class=+" dingen eruit gooit, die classes staan toch niet in een style sheet, dus nutteloos. Maar dat wil niet helemaal lukken.

Ik heb even weinig tijd, maar misschien kan ik snel even wat voor je betekenen
Je kunt je class attributen gewoon zo matchen, je wilt alles tot de volgende spatie of >

code:

s/class=[^ >]+//gi

Want voor zover ik in je voorbeeldje zie staan de classes toch niet tussen aanhalingstekens. Om rekening te houden met het geval waarin dat wel zo zou zijn (wellicht komt het voor, bijvoorbeeld classes met een spatie ertussen, die moeten wel), gaan we nog even door.
Zie hier een pattern dat tekst tussen doublequotes matcht, quotes mogen escaped in de tekst voorkomen:

code:

/"
    [^"\\]*
    (
        \\.
        [^"\\]*
    )*
"/gx

Met een beetje hulp uit MRE (ik neem niet aan dat je deze in 2 seconden doorhebt)

Wanneer we die gebruiken:

code:

s/
    class=
    "
        [^"\\]*
        (
            \\.
            [^"\\]*
        )*
    "
//gix

Combineren met de vorige en we hebben alle class attributes:

code:

s/
    class=                  # attribute
    (   "               # opening doublequote
            [^"\\]*         # 'normal'
            (
                \\.     # 'special'
                [^"\\]*     # 'normal'
            )*
        "               # closing doublequote

        |               # OR

        [^ >]+              # not quoted
    )
//gix

Houd je nog wel de extra spatie die overblijft van je class attribut, maar dat is niet zo erg (en eventueel gemakkelijk op te lossen).

Getest in perl, denk in PHP aan alle backslashes die je nodig hebt om te escapen.

En zijn er nog mensen die meer dingen er uit zouden filteren? ideeen? tips?

Hmmm ik zou er misschien zowiezo niet eens aan beginnen, het is eigenlijk onbegonnen werk
En tot 'mooie' HTML krijg je het toch nooit. En waarom wil je graag de class attributen eruit? Definieren die classes niet een deel van de opmaak (die je neem ik aan wilt behouden)?

Voor de mensen die geen Word hebben (lucky bastards), hier heb je een klein gedeelte word html.

Aaargh

drm: waarom gebruik je de "e" modifier in je regex
Je gebruikt toch geen functieaanroep in het 2e argument van preg_replace?

/e is hier inderdaad nogal nutteloos, maar als de /e weggehaald wordt zul je in de replace strings die je geeft ook de enkele quotes weg moeten halen.

[mbravenboer]

Als MS Word geldige XML kan uitpoepen (XHTML dus) kan je het ook heel eenvoudig verwerken met XSL.

Je hoeft in feite alleen maar de speciale gevallen op te geven. De rest kan gedaan worden met de identity stylesheet.

Dat is een STUK makkelijker dan deze ingewikkelde regex stuff. Het leren van XSL is hiervoor zeker de moeite.

[tomato]

mbravenboer: Als MS Word geldige XML kan uitpoepen (XHTML dus) kan je het ook heel eenvoudig verwerken met XSL.

Je hoeft in feite alleen maar de speciale gevallen op te geven. De rest kan gedaan worden met de identity stylesheet.

Daar heb je natuurlijk helemaal gelijk in. En ook een stuk flexibeler en minder foutgevoelig.

Dat is een STUK makkelijker dan deze ingewikkelde regex stuff.

Regex stuff

Het leren van XSL is hiervoor zeker de moeite.

Dat ben ik dan weer helemaal met je eens

[mbravenboer]

tomato: Regex stuff

Reguliere expressies zijn erg krachtig en worden natuurlijk ontzettend veel gebruikt... Ik zie ze echter ook erg veel misbruikt worden... De notaties van PHP/Perl/Java lenen zich naar mijn mening vooral voor het beschrijven van kleine structuren. Ze zijn een stuk minder geschikt voor grote problemen.

Daarvoor is het toch handiger om een parser te genereren uit een grammatica (waar dan weer reguliere expressies in zitten ) en verder met een abstract syntax tree te werken...

Toevoeging: waarom?
Je werkt dan minder concreet op de syntax. Bij herschrijvingen abstraheer je daar veel verder van en kan je gebruik maken van eenvoudige herschrijf-regels. Bij dergelijke regex oplossing ben je tijdens het herschrijven veel te veel met de syntax bezig... IMHO .

[tomato]

mbravenboer:
Reguliere expressies zijn erg krachtig en worden natuurlijk ontzettend veel gebruikt...

In bepaalde omgevingen uiteraard. Er zijn veel omgevingen waarin je van je leven geen reguliere expressies nodig zult hebben.

Ik zie ze echter ook erg veel misbruikt worden...

Daar heb je gelijk in. Ik maak mij er zelf ook wel eens schuldig aan, maar meestal ben ik mij er dan wel van bewust (in dit geval liep ik echter blind achter de topicstarter met zijn regexen aan, zonder het probleem even wat breder te bekijken ).

De notaties van PHP/Perl/Java lenen zich naar mijn mening vooral voor het beschrijven van kleine structuren.

De notaties niet zo zeer naar mijn mening. De werking van reguliere expressies intern geeft wel problemen bij het beschrijven van grotere structuren. Denk er wel aan dat regexen over het algemeen niet op zichzelf staan. Ze zijn onderdeel van een taal (in perl echt, in andere talen worden ze in iig in combinatie met die tal gebruikt).

Ze zijn een stuk minder geschikt voor grote problemen.

Grote problemen is niet het tegenovergestelde van kleine structuren
Beetje vage woordkeuze dus, maar nogmaals: het moet geen streven zijn een programma te schrijven met louter FA patronen.

Daarvoor is het toch handiger om een parser te genereren uit een grammatica (waar dan weer reguliere expressies in zitten ) en verder met een abstract syntax tree te werken...

Uiteraard, wanneer dit mogelijk is en het de moeite waard is heb je daar zeker gelijk in. Maar dat is niet altijd de moeite waard imho. Op deze manier worden regexen wel een beetje een quick tool voor een quick hack (tm) van Arien en misschien ligt daar ook wel een beetje de grote kracht. Maar om ze dan als seconde lijm te zien gaat me wat ver (niet bedoeld als quote van jou)

Toevoeging: waarom?
Je werkt dan minder concreet op de syntax. Bij herschrijvingen abstraheer je daar veel verder van en kan je gebruik maken van eenvoudige herschrijf-regels. Bij dergelijke regex oplossing ben je tijdens het herschrijven veel te veel met de syntax bezig... IMHO .

Ja, maar de syntax is precies waar het om draait bij dit soort problemen. Als je daar omheen wilt door een grammatica en een parser te gebruiken is fijn, maar hoe komt die grammatica tot stand? Precies, het is natuurlijk onmogelijk je niet bezig te houden met die syntax. Maar jij doet het liever generiek stopt dit weg op een ander niveau (wat natuurlijk heel mooi is ).

Voor sommige problemen blijven regexen toch een echte uitkomst. Voor het valideren van user input (en dan doel ik niet op UBB tags oid ) bijvoorbeeld zou ik ze soms niet willen missen.

[mbravenboer]

tomato: In bepaalde omgevingen uiteraard. Er zijn veel omgevingen waarin je van je leven geen reguliere expressies nodig zult hebben.

Je ziet het toch wel op erg veel plaatsen voorkomen... Het lijkt mij toch sterk dat een informaticus nooit iets met een grammatica doet? Iedereen schrijft toch weleens een DTD of gebruikt grep .

in dit geval liep ik echter blind achter de topicstarter met zijn regexen aan, zonder het probleem even wat breder te bekijken ).

Voor deze keer dan .

Grote problemen is niet het tegenovergestelde van kleine structuren Beetje vage woordkeuze dus

Ik drukte mezelf inderdaad niet zo goed uit . Wellicht is het aantal non-terminals bij een probleem een betere maat.

Ja, maar de syntax is precies waar het om draait bij dit soort problemen. Als je daar omheen wilt door een grammatica en een parser te gebruiken is fijn, maar hoe komt die grammatica tot stand? Precies, het is natuurlijk onmogelijk je niet bezig te houden met die syntax.

Mwah, daar ben ik het niet echt (echt niet ) mee eens... Je definieert voor de taal waarop je bezig bent een grammatica (als deze al niet beschikbaar is). Daarvoor heb je uiteraard te maken met de syntax van een taal.

Voor het implementeren van je transformatie (tenslotte transformeert alles ) ben je echter niet bezig met de syntax van de taal, maar met een abstracte representatie. Deze represenatie is volledig onafhankelijk van de syntax en kan bijvoorbeeld ook meer informatie bevatten. Er zijn in feite een aantal stadia:

1. Parse tree: boom die het resultaat is van het parsen van een stuk tekst.

2. Abstract syntax tree: irrelevante details zoals layout is verwijderd. Ook kan je nog wat constructies herschrijven om zaken wat prettiger te representeren.

3. ge-desugar-de abstract syntax tree: overbodig syntaxtische suiker kan verwijderd worden. Voor source -> source herschrijvingen gaat dit soms te ver, maar soms kan er ook weer heel gemakkelijk ge-sugar-ed worden.

4. Sematische toevoegingen: typisch vooral type informatie .

Je krijgt zo een representatie die vrijwel niets meer met de concrete syntax te maken heeft. Je transformatie wordt zo steeds declaratiever. Ook wordt de transformatie steeds makkelijker, omdat je over veel meer informatie beschikt...

Maar jij doet het liever generiek stopt dit weg op een ander niveau (wat natuurlijk heel mooi is ).

Inderdaad, en bij de implementatie van het probleem zelf heb je dus niet meer te maken met irrelevante details die de zaak onduidelijk maken. Bovendien heb je zo een smak aan componenten die je makkelijk kan hergebruiken .

Voor sommige problemen blijven regexen toch een echte uitkomst. Voor het valideren van user input (en dan doel ik niet op UBB tags oid ) bijvoorbeeld zou ik ze soms niet willen missen.

Daar doelde ik inderdaad vooral op als belangrijkste toepassing in mijn ogen .

[drm]

_{learning mode on....}

mbravenboer:
(...)

Er zijn in feite een aantal stadia:

1. Parse tree: boom die het resultaat is van het parsen van een stuk tekst.

2. Abstract syntax tree: irrelevante details zoals layout is verwijderd. Ook kan je nog wat constructies herschrijven om zaken wat prettiger te representeren.

3. ge-desugar-de abstract syntax tree: overbodig syntaxtische suiker kan verwijderd worden. Voor source -> source herschrijvingen gaat dit soms te ver, maar soms kan er ook weer heel gemakkelijk ge-sugar-ed worden.

* drm is niet zo'n terminoloog...
Wat bedoel je met suikeren?

4. Sematische toevoegingen: typisch vooral type informatie .

En wat met Sematisch?

Je krijgt zo een representatie die vrijwel niets meer met de concrete syntax te maken heeft. Je transformatie wordt zo steeds declaratiever. Ook wordt de transformatie steeds makkelijker, omdat je over veel meer informatie beschikt...

Oftewel: abstracter. Oftewel: meer schaalbaar.
toch?

[mbravenboer]

drm: Wat bedoel je met suikeren?

Dat heeft te maken met syntaxtische suiker. Syntaxtische suiker zijn constructies die alleen maar gebruikt worden om een makkelijkere syntax te bieden. In principe zijn er heel veel verschillende vormen van syntaxtische suiker. Voor sommige applicaties wil je heel ver desugaren, voor andere is dat juist weer niet mogelijk...

Typische desugaring operaties zijn:

1. Vertalen van constructies als while en for naar primtievere vormen of naar elkaar.

2. Overloading van optel operaties vertalen naar de echte operaties.

3. Makkelijke notaties (afkortingen) vertalen naar de voledige vorm (zie bijvoorbeeld de verkorte XPath notatie).

Bij Java kan je bijvoorbeeld gelijk variabelen een waarde geven in een klasse. In principe is dat gewoon syntaxtische suiker, want dit wordt gewoon in de constructor geplaatst. Hetzelfde geldt voor het static block. In principe geldt hetzelfde voor inner-classes

In principe komt alles er op neer dat je het aantal constructies in je taal omlaag gaat brengen, zodat je minder gevallen hoeft af te handelen (minder non-terminals).

En wat met sematisch?

Semantiek heeft te maken met betekenis. Semantische analyse van een abstract syntax tree wordt gebruikt om de betekenis van items te achterhalen. Met semantische operaties worden vaak de operaties bedoeld die in een grammatica zijn opgenomen. Deze operaties worden uitgevoerd bij het parsen van een file.

Oftewel: abstracter. Oftewel: meer schaalbaar. toch?

Tja, schaalbaar... in principe wel. Het belangrijkste aspect is het laag houden van de lokale complexiteit. Het geheel is opgebouwd uit componenten, waardoor je per component een probleem kunt oplossen, zonder dat je aan de problemen van andere componenten hoeft te denken. Iets concreter: als je een transformatie aan het uitvoeren bent, maak je je niet druk om de syntax van een stukje boom (parsen + pretty-printen). Je componenten worden zo zelfstandiger en dus beter aan te passen .

[LuCarD]

tomato
En tot 'mooie' HTML krijg je het toch nooit. En waarom wil je graag de class attributen eruit? Definieren die classes niet een deel van de opmaak (die je neem ik aan wilt behouden)?

Mooie HTML is wel mijn streven, maar ik weet dat het niet mogelijk is.

De Classes die er in staan die staan niet in mijn stijl sheet. En worden dus ook niet gebruikt. Ik heb mijn 4 huidige regEx losgelaten op een Word HTML van 3 pagina's. De orgineele groote is 18665 bytes. Na 4 simpele regex 11000 bytes. (dat is 41% troep weggegooit).
En op het oog zit de pagina er nog het zelfde uit!

mbravenboer
Als MS Word geldige XML kan uitpoepen (XHTML dus) kan je het ook heel eenvoudig verwerken met XSL.

Dat is een STUK makkelijker dan deze ingewikkelde regex stuff. Het leren van XSL is hiervoor zeker de moeite.

Oke, ben ik wel met je eens. Maar het probleem is dat ik het word document moet intregeren in een bestaand ontwerp. Met andere woorden hij komt in een tabel te staan.

mbravenboer
Toevoeging: waarom?
Je werkt dan minder concreet op de syntax. Bij herschrijvingen abstraheer je daar veel verder van en kan je gebruik maken van eenvoudige herschrijf-regels. Bij dergelijke regex oplossing ben je tijdens het herschrijven veel te veel met de syntax bezig... IMHO.

Je moet je toch een keer bezig houden met de syntax. En aangezien dit maar een klein gedeelte van het geheel is heb ik voor de "quick hack" gekozen.

tomatoVoor sommige problemen blijven regexen toch een echte uitkomst. Voor het valideren van user input (en dan doel ik niet op UBB tags oid ) bijvoorbeeld zou ik ze soms niet willen missen.

Dat ben ik toch eigenlijk aan het doen

mbraveboer
Voor het implementeren van je transformatie (tenslotte transformeert alles ) ben je echter niet bezig met de syntax van de taal, maar met een abstracte representatie.

<SNIP>

Je krijgt zo een representatie die vrijwel niets meer met de concrete syntax te maken heeft. Je transformatie wordt zo steeds declaratiever. Ook wordt de transformatie steeds makkelijker, omdat je over veel meer informatie beschikt...

You lost me there

[mbravenboer]

LuCarD: Oke, ben ik wel met je eens. Maar het probleem is dat ik het word document moet intregeren in een bestaand ontwerp. Met andere woorden hij komt in een tabel te staan.

Dat maakt helemaal niets uit.... sterker nog, XSL maakt het nog makkelijker .

Je moet je toch een keer bezig houden met de syntax.

Inderdaad, maar dat kan onafhankelijk van je probleem: door middel van een parser en een pretty-printer component. Die kun je hergebruiken voor al je transformatie problemen.

Bij het gebruik van XSL hoef je je zelfs niet bezig te houden met deze componenten omdat ze standaard aanwezig zijn.

En aangezien dit maar een klein gedeelte van het geheel is heb ik voor de "quick hack" gekozen.

Dat is inderdaad waar, mijn voorstellen vragen natuurlijk veel werk. Behalve als je XML+XSL gebruikt. Dan het je standaard componenten tot je beschikking. Deze hack is niet meer quick als je ook op XML kan werken .

You lost me there

In dit geval is die opmerking niet zo relevant omdat HTML een opmaaktaal is en geen programmeertaal. Ook is HTML in feite al een soort abstract syntax tree. Er is dan ook niet veel meer informatie die je kan gebruiken.

Wel kan je door het gebruik van een transformatie-taal (XSL dus) behoorlijk wat abstraheren en een duidelijkere specificatie van je transformatie bereiken. De correctheid van je transformatie is dan makkelijker in te zien. Ook is het makkelijker om je transformatie verder uit te breiden.

[drm]

mbravenboer legde even uit wat syntactische suiker is

OK

mbravenboer legde even uit wat semantiek is

En nog 's OK

[flauw]
_{Volgende keer misschien wat zorgvuldiger zijn met spellen?}

4. Sematische toevoegingen: typisch vooral type informatie

[/flauw]

mbravenboer:
Tja, schaalbaar... in principe wel. Het belangrijkste aspect is het laag houden van de lokale complexiteit. Het geheel is opgebouwd uit componenten, waardoor je per component een probleem kunt oplossen, zonder dat je aan de problemen van andere componenten hoeft te denken. Iets concreter: als je een transformatie aan het uitvoeren bent, maak je je niet druk om de syntax van een stukje boom (parsen + pretty-printen). Je componenten worden zo zelfstandiger en dus beter aan te passen .

Ok, duidelijk. Dat was even de andere kant op gedacht

thnx

[mbravenboer]

drm: OK, En nog 's OK , Ok, duidelijk,thnx

Mooi .

Volgende keer misschien wat zorgvuldiger zijn met spellen?

Beidehant .

[wasigh]

Op vrijdag 16 november 2001 11:34 schreef mbravenboer het volgende:

Beidehant .