WORD ALS XML-AUTEURSOMGEVING

"THE INSIDE STORY"

door Geert Josten en Peter Kester,GeertJosten@daidalos.n1 Peter.Kester@daidalos.nl

"Is Microsoft Word geschikt als XML/SGML-auteursomgeving?" Deze vraag is door onze klanten

de afgelopen jaren vaak aan ons gesteld, maar ze Iaat zich niet zo eenvoudig beantwoorden.

Waarom uberhaupt voor Word kiezen? Hoe moet het deel uitmaken van de werkwijze en de

workflow? In hoeverre moet de auteur van ondersteunende functionaliteit voorzien worden?

Etc. etc. Elk van deze vragen belicht een ander aspect van de oorspronkelijke vraag.

PAG 1)10,4

Dit artikel probeert inzicht te geven in een aantal vandeze aspecten, baserend op de binnen Daidalos opgeda-ne ervaring. Met deze informatie moet het naar onzemening mogelijk zijn om de bovenstaande vraag voorjezelf te beantwoorden, maar ook om een idee te krijgenwelke vorm de auteurstool moet hebben. Tevens wordtaandacht besteed aan Microsoft Word 2003, waarop veleogen verwachtingsvol gericht zijn. Microsoft claimt dathet ingebouwde XML-ondersteuning biedt. Is dit inder-daad zo en biedt dit nieuwe perspectieven in relatie totde bovengestelde vraag?

Achtergrond

Bij Daidalos is op diverse manieren ervaring opgedaanmet het bewerken van SGML en XML via Microsoft Word.Dit omvat verschillende conversietrajecten van en naarRTF alsmede sjablonen en plugins voor Word. De ont-wikkelingen van Microsoft op het gebied van XML-func-tionaliteit worden hiervoor nauwlettend in de gatengehouden.

Waarom Word?

Indien iemand vraagt of Word zonder meer geschikt isals SGML/XML editor, is het meest voor de hand liggendeantwoord: "Nee". In ieder geval voor de versies ouderdan 2003. Word is een opmaakgericht pakket; What yousee is what you (expect to) get. Een auteur wordt nietgedwongen om een bepaalde volgorde of structuur tehanteren en kan naar believen stijlen en opmaak toevoe-gen, wijzigen of verwijderen. Puur het feit dat WordBeen SGML of XML kan inlezen is voldoende om de stel-ling te staven, versie 2003 buiten beschouwing gelaten.Is Word dan helemaal niet geschikt om SGML/XML tebewerken? Nee, dat ook weer niet. De bovengenoemdeopmerkingen druisen echter sterk in tegen de ideeenachter SGML en XML. XML en SGML zijn juist bedoeldom content te abstraheren van opmaak. Dan is het dusniet bepaald voor de hand liggend om in een pakket alsWord SGML of XML te bewerken. Bovendien is er altijdeen vertaling van SGML/XML naar een voor Word lees-baar formaat nodig.Daar staat tegenover dat veel auteurs geen SGML/XML-

specialisten zijn. In veel gevallen is men zelfs nauwelijksbekend met SGML of XML. Softwarepaldketten als Wordzijn algemeen bekend en beschikbaar en deze applica-ties kennen een lage drempel, zeker vergeleken met demeeste bekende volwaardige SGML/XML-editors. Door deinformatie uit de XML/SGML-documenten op een speci-fieke manier te presenteren in Word, is het voor auteursmogelijk deze informatie te bewerken, zonder dat zedaar feitelijk XML- of SGML-kennis voor nodig hebben.Hiermee wordt het mogelijk de bewerking door auteursaan te sluiten op geautomatiseerde workflow-systemen.De brede beschikbaarheid en de algemene bekendheidvan Word en het feit dat de meeste auteurs al in een der-gelijk pakket werken, is voor de meeste klanten de door-slag om in ieder geval een poging te wagen, het bewer-ken van XML/SGML met Word te proberen.

Implicaties gebruik Word

De keuze om Word als XML auteursomgeving te gebrui-ken heeft enige implicaties. Word moet geschiktgemaakt worden om de activiteiten die de auteurs die-nen te verrichten mogelijk te maken. Daarvoor is de vol-gende functionaliteit van belang:n inlezen en wegschrijven van XML/SGML,n auteursondersteunende functionaliteit.

Deze punten worden hieronder toegelicht.

Inlezen en wegschrijven van XMLISGML

Om XML of SGML te kunnen bewerken met MicrosoftWord, moet het ingelezen kunnen worden. Hiervoor zijntwee mogelijkheden:n rechtstreeks (via Word-API en Worddocument objectmo-

del),n indirect (via tijdelijk bestand met Word-compatible

bestandsformaat).

Het is mogelijk om XML of SGML rechtstreeks in telezen. Met Word 2003 is dat (voor XML) eenvoudig, maardit pakket is duur en zwaarlijvig (dit komt later nog aande orde). Bij oudere versies van Word moet daarvoor zelffunctionaliteit uitgewerkt worden. Dat legt nogal wat

JAARGANG 10 • NR 2

1--I

<!ELEMENT

beperkingen op, aangezien je athankelijk bent van defunctionaliteit die Microsoft je biedt om hetWorddocument-objectmodel (de programmeerinterfacedie Microsoft biedt) te bewerken, wat bij de oudere ver-sies van Word erg beperkt is.Daarom is de meest gebruikelijke methode nog altijdom het eerst om te zetten naar een bestandsformaat datWord kan inlezen en wegschrijven. En daarvoor zijnslechts een beperkt aantal alternatieven beschikbaar,waarvan feitelijk alleen HTML en RTF interessant zijn.

De meeste andere formaten (onder andere Word enWordPerfect) zijn binair en op speciale wijze gecodeerd.Dit maakt de technische verwerking onnodig ingewik-keld indien je de vertaling naar een ander formaat bui-ten Word om wilt realiseren. De overige tekstuele forma-ten (onder andere DOS-tekst, eventueel met beperkteopmaak) bevatten te weinig structurele en opmaakgere-lateerde informatie.HTML en RTF zijn beide tekstueel en bevatten beide inredelijke mate opmaak en structuur informatie.Voldoende om daarmee bewerking van SGML/XML metWord mogelijk te maken. HTML is wat eenvoudiger quaopzet, RTF biedt meer mogelijkheden om informatie uitte wisselen.Bij Daidalos is in de meeste gevallen gekozen voor RTFwaartoe het verdere verhaal zich dan ook beperkt.Problemen rond het werken met RTF komen later in ditverhaal ter sprake. Microsoft Word 2003 komt afzonder-lijk nog ter sprake.

Auteursondersteunende functionaliteit

Het converteren van XML of SGML naar RTF heeft alseffect dat de hierarchische structuur (grotendeels) verlo-ren gaat. Anders gezegd, de hierarchische structuurwordt veelal vertaald naar een voor de structuur ken-merkende (lineaire) volgorde van opmaakprofielen. Eenonjuiste volgorde heeft bij terugvertaling een invalidestructuur tot gevolg.Dit heeft zijn weerslag in het bewerken van de structuurin Word. Van de auteur zal gevraagd worden op een spe-cifieke manier zijn document van 'impliciete' structuurte voorzien, door onder andere specifieke stijlen in dejuiste volgorde te hanteren. Het is zinvol om de auteurdaarbij te ondersteunen middels functies voor automati-sche controle op correctheid en voor het wijzigen ofinvoegen van ingewikkelde structuren.

De automatische controle kan een continue controlezijn, die bij iedere bewerking van de auteur controleertof het resultaat nog klopt. Dit is de manier waarop demeeste XML editors te werk gaan. Zij verbieden daarbijvaak bewerkingen die een invalide situatie kunnen ver-oorzaken. Dit kan ook een mogelijkheid zijn in Word alsauteurstool, maar het dwingt de auteur daarbij heelsterk bewerkingen in een specifieke volgorde uit te voe-ren om te zorgen dat de `structuur' te allen tijde valideis. Dit zal snel als onprettig ervaren worden als deauteur daardoor gedwongen is of te wijken van zijngebruikelijke werkwijze. Bovendien kan dit veel van hetsysteem eisen, vooral indien hiervoor op de achtergrond

een XML-versie van het document bijgewerkt moet wor-den bij iedere muisklik of toetsaanslag van de auteur.Het is ook mogelijk om een handmatig te starten functiebeschikbaar te stellen die de validiteit van het documentop verschillende aspecten controleert. Indien technischmogelijk, moet in ieder geval een validatie op basis vanhet SGML/XML-eindresultaat tot de mogelijkheden beho-ren. Verder kan een controle op bijvoorbeeld stijlvolgor-de of correct gebruik van tabellen en figuren beschik-baar gesteld worden.

Omdat Word niet specifiek bedoeld is om als SGML/XML-auteursomgeving te dienen, zijn vaak speciale of bewer-kelijke handelingen vereist om bepaalde structuren in tevoegen. Denk daarbij aan het invoegen van afbeeldin-gen, tabellen, kruisverwijzingen of veel voorkomendestramienen om uit te werken. Daarom zijn naast contro-lefuncties ook bewerk- en invoegfuncties wenselijk. Eencontrolefunctie kan de auteur begeleiden bij het bewer-ken door te waarschuwen voor onjuiste werkwijzen,maar minstens zo handig zijn functies die automatischdergelijke structuren op de juiste wijze invoegen. Dezefuncties zijn betrekkelijk eenvoudig uit te werken enworden hoog gewaardeerd.

Integratie met Word

Zoals hierboven uitgelegd, is inlezen en wegschrijvenvan XML/SGML niet zonder meer mogelijk. Daarvoormoeten conversies uitgevoerd worden van XML/SGMLnaar bijvoorbeeld RTF en vice versa. Men kan zich devraag stellen of de conversie vanuit Word gestuurd moetkunnen worden (geintegreerde conversie) of dat dezebuiten Word om plaats moet vinden.

Kort gezegd kan men spreken van vier gradaties waarinintegratie met Word kan worden doorgevoerd:n geen integratie,n gescheiden conversie en bewerking,n geintegreerde conversie,n toekomst: geen conversie?

Voor auteursondersteunende functionaliteit is dezevraag uiteraard niet aan de orde, aangezien deze altijdgeIntegreerd moet zijn met Word. Maar het vraagstuk,afzonderlijk of geintegreerde conversie, heeft wel dege-lijk zijn weerslag op de mogelijkheden met betrekkingtot deze functionaliteit. Dit hangt samen met de archi-tectuur van de auteurstool.De verschillende gradaties worden hieronder naderbesproken.

Geen integratieDoor niet met Word te integreren wordt het eenvoudig-ste systeem gerealiseerd. Dit heeft belangrijke voordelen.Licentie-, installatie- en updateperikelen zijn aanauteurszijde niet aan de orde en zij kunnen in grote lij-nen doorgaan met de gebruikelijke werkwijze. Het geeftook veel vrijheden ten aanzien van de integratie van deconversies in de workflow aan de niet-auteurszijde.Vooral bij grote en wisselende groepen (freelance)

PAG

5

<!ELEMENTJAARGANG 10 • NR 2

I-1

Bewerkenin Word

OpslagTussen-formaat

4(1 PAG

6

<!EL€MENT

auteurs kan dit van doorslaggevend belang zijn. Fenaangepaste auteursinstructie moet afdekken dat eenauteur om kan gaan met de 'impliciete' structuur in dedocumenten. Ook voor auteurs die om de een of anderereden niet over willen stappen op een volwaardigeXML/SGML-editor is dit een optie.

Figuur 1: Geen integratie van conversie in Word

Deze aanpak heeft echter als belangrijk nadeel, dat geenauteursondersteunende functionaliteit geboden kanworden. Deze moet namelijk met Word geintegreerdworden. Deze variant omvat dan ook uitsluitend eenconversie van en naar XML/SGML, waarbij het geconver-teerde XML/SGML in alle vrijheid geopend en bewerktkan worden in Word of desgewenst in een ander pakketdat RTF ondersteunt. Let wel: ook macrofuncties in eenWordsjabloon zijn feitelijk een vorm van integratie metWord.Dit heeft niet alleen effect op de auteur die ondersteu-nende functionaliteit moet ontberen, maar ook eengeautomatiseerde terugconversie kan hierdoor voor pro-blemen komen te staan. Omdat de auteur niet gestuurdwordt in zijn werk, kan deze gemakkelijk en ongemerktlouten . maken. De juistheid van de volgorde van stijlenis voor een mens niet altijd even gemakkelijk te beoorde-len, maar is voor een geautomatiseerde terugconversievan cruciaal belang. Handmatige interventie kan al snelnoodzakelijk zijn.Kortom, in deze variant wordt de auteur veel bewegings-vrijheid gegeven, maar wellicht teveel om de workflowgoed te automatiseren.

Het praktijkvoorbeeld MCV2 zonder het gebruik vanWord-sjablonen is hiervan een voorbeeld. Het praktijk-voorbeeld WordShadow, indien een redacteurWordShadow als conversietool gebruikt en het RTF door-stuurt naar een auteur, is hiervan een ander voorbeeld.Deze voorbeelden komen onder het kopje 'De Praktijk'uitgebreid aan de orde.

Gescheiden conversie en bewerking

Het is echter mogelijk beperkte auteursondersteunendefunctionaliteit ter beschilddng te stellen, bijvoorbeeld inde vorm van macrofuncties in een Wordsjabloon of vaneen stijlvolgorde-controlefunctie. Dit houdt de licentie-kosten en tijd die besteed moet worden aan installatiesbeperkt. Dergelijke sjablonen zijn bovendien veelal zo temaken dat ze compatibel zijn met meerdere versies vanWord. Het distribueren van updates kan echter een nete-

lige kwestie zijn als er geen formele installatie is uitge-werkt van dergelijke sjablonen en deze sjablonen alslosse bestanden rondgestuurd worden.Ook voor deze variant geldt dat het geconverteerde XMLof SGML door de auteur geopend en bewerkt wordt inWord. Dit document in tussenformaat, oftewel RTF, kannet als bij de vorige variant ergens klaargezet zijn voorbewerking of het wordt toegezonden per e-mail.

Het belangrijkste nadeel aan deze aanpak is dat slechtsbeperkte ondersteunende functionaliteit mogelijk is.Deze kan zich namelijk uitsluitend op het tussenfor-maat en op de binnen Word beschikbare mogelijkhedenrichten. Bijvoorbeeld een functie die referenties in delopende tekst automatisch herkent en markeert, kan datalleen uitgevoerd worden conform de auteursinstructiesvoor het tussenformaat. Deze functionaliteit is dusdirect afhankelijk van de wijze waarop structuur gere-presenteerd wordt in het tussenformaat. Met geinte-greerde conversie is het mogelijk dit op de XML/SGMLstructuur te doen en dat opnieuw naar RTF te vertalen,zonder dat de auteur bier veel van merkt.

Figuur 2: Geen conversie maar wel bewerkfuncties in Word

MCV2 is het praktijkvoorbeeld dat bier het meest bijaansluit. Dit voorbeeld komt verderop aan de orde.

Geintegreerde conversie

Als nog een stap verder gegaan wordt, door de conversiemet Word te integreren, komt deze niet alleen binnenhandbereik van de auteur, maar is het ook mogelijk omauteursondersteunende functionaliteit aan te bieden diezich richt op de echte XML/SGML-structuur.Denk aan iets eenvoudigs als de XML/SGML-structuurweergegeven in een boomweergave, vergelijkbaar aan deDocumentstructuur, maar dan gebaseerd op de struc-tuur die we kennen van XML/SGML.Het is mogelijk om een controlefunctie toe te voegen diezich niet of niet alleen richt op stijlvolgorde, maar ookop de XML/SGML-structuur (na bewerking en conversie).Hierdoor kan aan de gebruiker (auteur of redacteur)direct feedback gegeven worden over onjuistheden inhet document, of kan de gebruiker aan de hand van deXML/SGML-structuur zelf beoordelen of de huidige sta-tus van het document het gewenste resultaat in deXML/SGML-structuur zal opleveren.Ook functies om bewerkingen op de XML/SGML-struc-tuur uit te voeren of functies die een preview van hetdocument in de uiteindelijke layout tonen, behoren nu

JAARGANG 10 • NR 2

Preview

Tussen-formaat

Structuur-weergave

Bewerkenin Word Opslag

tot de mogelijkheden. Dit zijn dus alle zeer interessantevoordelen, hoewel wellicht niet alle interessant voor eenauteur, maar misschien eerder voor een redacteur.

Deze functionaliteit kan in een ActiveX DLL (plugin)gevangen en via een Word-sjabloon (met bijvoorbeeldeen knoppenbalk) toegankelijk gemaakt worden. Hetbelangrijkste nadeel is dat deze variant een degelijkeinstallatie vereist en mogelijk licentiekosten met zichmeebrengt. Updates, ook van de conversie zelf, moetenexpliciet naar alle gebruikers van de auteurstool uitge-rold worden. Bovendien wordt de conversie door degebruiker van de auteurstool gestuurd en is dus nietzonder meer te integreren in een geautomatiseerdeworkflow.

Figuur 3: Geintegreerde conversie in Word

Een interessante mogelijkheid is om bijvoorbeeld eenredactie (`front-office') uit te rusten met een dergelijkeapplicatie. Zij converteren dan de te bewerken documen-ten en sturen die (als RTF of Word-doc) naar de relevanteauteurs. De auteurs werken in een reguliere Word-versieof vergelijkbare applicatie en sturen het bewerkte docu-ment terug. De front-office controleert het werk metbehulp van de controlefuncties en converteert de docu-menten weer naar XML/SGML. Dit voorkomt grootschali-ge installaties en hoge licentiekosten en maakt eengecontroleerde verbinding tussen auteurs en workflowmogelijk.

WordShadow is het praktijkvoorbeeld dat hier het meestbij aansluit. Dit voorbeeld komt nog aan de orde.

voor de auteurs te verbergen. Nu kunnen ook met dezevolwaardige editors dergelijke coderingen ofwel markupverborgen en de informatie aantrekkelijk gepresenteerdworden, maar vergeet dan niet dat deze applicaties rela-tief zwaar zijn. Er moet veelal geconfigureerd worden enze brengen vaak hoge licentiekosten met zich mee, voor-al als deze breed uitgerold moeten worden onder eengrote hoeveelheid auteurs en redacteuren. Verder is dewerkwijze principieel anders. In plaats van op eenopmaakgericht document te werken, werkt men in feiteop een hierarchische structuur. En ook al ziet de gebrui-ker dat niet direct, hij zal dat wel merken aan de manierwaarop hij bewerkingen mag doorvoeren.

Komt dan nu eindelijk Word 2003 ter sprake? Ja, maarvoorlopig nog slechts kort. Met Word 2003 kunnen XML-bestanden (geen SGML!), al dan niet met een eigen DTD(feitelijk Schema), geimporteerd, bewerkt en weer opge-slagen worden. Het biedt daarnaast alle reeds van eerde-re versies van Word bekende functionaliteiten om dedaarin aanwezige informatie te voorzien van opmaak.Ook zijn enkele nieuwe mogelijkheden toegevoegd ombijvoorbeeld dynamisch informatie te tonen. Dit sluitdus uitstekend aan bij ons geschetste ideaal, maar is ditideaal wel zo ideaal als het lijkt?

Het punt is namelijk dat als het document waar eenauteur aan werkt in feite het XML-document is, dan zaldit, net als in iedere XMLISGML-editor, hoe dan ookmerkbaar zijn voor de auteur. Veel bewerkfuncties zul-len een XML-achtige insteek hebben. Denk bijvoorbeeldaan functies als het bewerken van attributen. Ook zoietsals een selectie maken in het document kan niet langerwillekeurig. Deze worden automatisch aangepast omaltijd stukken zogeheten well formed XML te omvatten.Nu kunnen in Word 2003 beide tactieken gehanteerdworden: zowel een opmaakgericht document bewerken,of een hierarchisch (XML) document. Bij de tweede tac-tiek gebruik je Word echter als een ordinaire XML-edi-tor, hetgeen nu juist niet de bedoeling is. Bij de eerstetactiek zul je toch weer het een en ander moeten pro-grammeren.

We zullen later in dit artikel nog uitgebreid terugkomenop het werken met Microsoft Word 2003.

Toekomst: geen conversie?

Het ideaal lijkt dan uiteraard de situatie waarin conver-sie niet nodig is en XML/SGML rechtstreeks in te lezen is,zonder dat daar functionaliteit voor geschreven hoeft teworden. Ook de aanwezigheid van auteursondersteunen-de functies als generieke bewerkfuncties en de controle-functie op de XML/SGML-structuur, zonder dat daarwerk voor verricht hoeft te worden, hoort uiteraard bijdit ideaal.

De tools die hier geheel aan voldoen, zijn de volwaardigeXML/SGML-editors. Maar daar waren de auteurs nu juistniet erg bekend mee (zie inleiding). Het is dus tevens hetdoel om in zo'n auteurstool de XML/SGML-coderingen

Conversieperikelen

Down-conversie (conversie van gestructureerd, lees XML ofSGML, naar `ongestructureerd', lees niet-XML)SGML)betekent kwaliteitsverlies. Een conversie van XML/SGMLnaar RTF is te vergelijken met een conversie van eenBMP-afbeelding naar een JPG-afbeelding. Een deel van dedetails gaat verloren. Dit moet zo goed mogelijk onder-vangen worden, want het is in deze situatie de bedoe-ling om na de bewerking door de auteur alle oorspron-kelijke details, voor zover niet gewijzigd, te herstellen.Dit wordt ook wel round-trippen genoemd.Zoals al eerder uitgelegd, biedt RTF relatief veel moge-lijkheden om informatie te presenteren. Het heeft ech-ter ook zijn beperkingen, die het round-trippen gecompli-

PAG /4>7

<!ELEMENTJAARGANG 10 • NR 2

ceerd maken. Deze worden in de onderstaande paragra-fen uit de doeken gedaan.

Round-

Figuur 4: Round-trippen tussen SGML/XML en RTF

Nog een belangrijke beperking, die niet voor RTF speci-fiek geldt, is de DTD-afhankelijkheid van de conversiesvan en naar XML/SGML. Theoretisch moet bij iedere wij-ziging van de DTD de conversie aangepast worden of tenminste opnieuw getest. Dit is vooral vervelend voor deoplossingen met een geintegreerde conversie, aangezienvoor deze oplossingen geldt dat de auteurstools opnieuwuitgerold moeten worden naar alle gebruikers.

• Complicaties gebruik RTF

Het gebruik van RTF biedt veel mogelijkheden voor hetpresenteren van informatie, maar heeft uiteraard ookzijn beperkingen. Het is principieel niet bedoeld omstructurele informatie te presenteren. Bijvoorbeeld spe-cifieke XML/SGML-zaken als commentaren, procesin-structies, attributen en structurering van elementenzijn niet op normale wijze weer te geven. En dat islogisch ook, want RTF is opmaakgericht. Dit toch tonenzal de opmaak van het document verstoren en dezeinformatie zal niet beveiligd zijn tegen ongewenste wij-zigingen. Het gaat hierbij om conceptuele problemen (integenstelling tot technische).

De belangrijkste problemen zijn:n RTF is opmaakgeorienteerd,n RTF kent geen dieptestructuur,n RTF kent onhandige notatie voor tabellen en

dergelijke,n RTF biedt beperkte mogelijkheden voor inline

structuur,n RTF biedt beperkte mogelijkheden voor bescherming

tegen ongewenste bewerkingen.

Deze worden hieronder besproken.

Opmaak versus round-trippenAlle informatie uit de bronbestanden moet opgeslagenworden in het RTF-bestand om bij terugconversie her-steld te kunnen worden (het round-trippen). Deze moetgeprojecteerd worden op opmaakgerelateerde informa-tie of anders voorzien worden van tekstuele markerin-gen. RTF biedt geen andere mogelijkheden. Hierdoormoet de codering uit de bron volledig hersteld worden

PAG

<!ELEMENTJAARGANG 10 • NR 2

op basis van de informatie uit het RTF. (Zie ook afbeel-ding bij Conversieperikelen.)

Hiervoor biedt RTF hoofdzakelijk de volgende middelen:n paragraaf en karakterstijlen (kunnen niet genest

worden!),n paragraaf en karakteropmaak (nadruk, kleur,

marges, uitlijning, omkadering, etc.),n hyperlinks en verschillende andere typen velden,

waaronder gelinkte afbeeldingen,n verborgen tekst,n sectie structuur met de mogelijkheid secties te

beveiligen tegen bewerking,n tabellen en kolomindelingen,n opsommingen en dergelijke.

In veel gevallen wordt besloten niet alle informatie tebehouden bij de heen- en terugconversie. In een aantalgevallen wordt deze informatie naderhand met de handen/of deels geautomatiseerd teruggeplaatst in hetbewerkte document. Zie bijvoorbeeld praktijkvoorbeeldMCV2.Uit ervaring is gebleken dat vertaling naar stijlen en ver-der zoveel mogelijk gebruik maken van RTF-eigenopmaakfuncties de beste tactiek is. VerborgenSGML/XML-codes of attribuutgegevens ingevoegd als ver-borgen tekst zijn bijvoorbeeld zeer gevoelig voor onge-wenste bewerking.Omdat dit maar beperkte middelen biedt, heeft dit bijeen round-trip (een heen- en een terugconversie) bijnaaltijd verarming van de structuur van de content totgevolg.

RTF is plat, XMLISGML is diep

RTF kent geen dieptestructuur. RTF bestaat uit eenlange, lineaire lijst van alinea's, eventueel onderverdeeldin meerdere, niet verder verdiepte secties. De diepte-structuur zoals zichtbaar in de weergave van deDocumentstructuur in Word is gebaseerd op een stati-sche niveau-indicatie die gekoppeld is aan stijlnamen.De feitelijke inhoud is lineair. Dit heeft twee gevolgenvoor terugconversie:n de impliciete structuur moet expliciet gemaakt

worden,n geen ruimte voor `onzichtbare' structuur.

De impliciete structuur is erg beperkend. De `diepte' vaneen alinea is, zoals gezegd, afgeleid van een statischniveau. Elementen kunnen daarentegen in veel gevallenop verschillende dieptes voorkomen. Daarnaast wordtmet stijlen over het algemeen - omdat dat natuurlijkeroverkomt - uitsluitend het begin van elementen aange-duid, maar niet het einde. Kopstijlen geven daarbij aandat mogelijk een wisseling in diepte plaatsvindt. Dezegeven echter niet altijd aan in welke richting en aange-zien het einde van elementen veelal niet weergegevenwordt in RTF, leidt dit al snel tot ambiguiteiten. Ookbevatten SGML/XML-documenten veel elementen dieslechts andere elementen omhullen om deze op eenlogische manier onder te verdelen. Deze elementenbevatten dus geen tekst en zijn derhalve niet zomaar te

representeren in RTF. Deze zijn dus zogezegd `onzicht-baar' in het RTF-formaat.

Het is mogelijk om voor iedere keer dat een elementopent en sluit een alinea met een label en een stip in tevoegen, maar dat maakt het voor de auteur niet over-zichtelijker en het komt niet logisch over. Bovendienwordt dan van de auteur geeist dat deze ook op diemanier te werk gaat, hetgeen een gedegen kennis van detoegestane structurering oftewel van de DTD vereist. Eneen van de uitgangspunten is juist dat de auteurs diekennis veelal niet hoeven te hebben.

Om de diepte die in zogezegd alle bronbestanden aanwe-zig is, te herstellen en zo goed mogelijk te anticiperenop ambigue situaties, dienen dus ingewikkelde algorit-mes uitgewerkt te worden, die vaak geheel afwijken vande algoritmes die de vertaling naar RTF realiseren. Hetherstellen van de dieptestructuur is dan ook werkelijkeen complexe opgave.Een van de meest flexibele methodes die we bij Daidaloshebben uitgewerkt, hanteert een configuratiebestandwaarin een hierarchische beschrijving van de stijlvolgor-de is opgenomen, in de vorm van een BNF-grammatica(BNF staat voor Backus Naur Form). Daaruit is dus bijvoor-beeld af te leiden dat twee verschillende stijlen hierar-chisch onder elkaar of juist naast elkaar horen. Hiermeeis in hoge mate mogelijk de originele structuur te herlei-den. Deze aanpak wordt gebruikt in het praktijkvoor-beeld MCV2.

RTF tabellen onhandig gestructureerd

Bronbestanden bevatten vaak tabellen, gecodeerd opspecifieke wijzen (denk aan standaarden als CALS). Dewijze waarop tabellen uitgewerkt zijn in RTF - ingewik-keld en onlogisch - wijkt daar hoe dan ook van af, watingewikkelde algoritmes om dat te vertalen en te her-stellen noodzakelijk maakt. Hetzelfde geldt voor zakenals afbeeldingen, lijsten, kruisverwijzingen, voetnotenen dergelijke.Voor tabellen is een expliciete vertaling tussen SGML enRTF gerealiseerd. Deze probeert zoveel mogelijk eigen-schappen van een SGML-tabel over te zetten naar eigen-schappen van de RTF-tabel en vice versa bij de terugver-taling. Nadeel is echter dat iedere DTD een andere tabel-definitie kan hanteren. Voor iedere definitie moet devertaling opnieuw uitgewerkt worden, eventueel deelsgebaseerd op een bestaande vergelijkbare vertaling.Gelukkig valt dit in de praktijk nogal mee, aangezienhet CALS-tabelmodel populair is en de meeste anderetabelmodellen hierop lijken.

Vrijwel geen structuur binnen RTF alinea's

In veel gevallen wordt binnen alinea's een diepe struc-tuur toegestaan, mogelijk zelfs recursief. Denk aan voet-noten binnen opsommingen of citaten, die wellicht zelfook weer in een voetnoot staan, niet vergetend dat op demeeste plaatsen ook nog zaken als nadruk toegestaanzijn. Dit is lastig weer te geven in RTF. Vooral construc-ties die niet op natuurlijke wijze op het RTF-formaat

geprojecteerd kunnen worden, zijn lastig. Onderscheidtussen allerlei verschillende typen verwijzingen of ver-wijzingen binnen verwijzingen vereisen al trucjes omdit op overzichtelijke wijze aan een auteur te presente-ren. Vaak moet een compromis gezocht worden tussenbehoud van structuur en bewerkbaarheid voor auteur.Hoe complexer de DTD-structuur binnen alinea's, hoelastiger dit probleem. (Zie ook het volgende punt.)

Weinig bescherming tegen ongewenstebewerkingen

RTF biedt slechts beperkte mogelijkheden om te voorko-men dat een auteur ongewenste bewerkingen uitvoert.RTF kent de mogelijkheid secties te beveiligen, zodat eendocument als een soort invulformulier te gebruiken is,maar dit is onvoldoende om te beschermen tegen onge-wenste wijzigingen binnen een alinea.Als bijvoorbeeld een verwijzing gepresenteerd wordt alseen hyperlink en de inhoud van de hyperlink is een spe-ciale code die niet gewijzigd mag worden, dan biedt RTFnoch Word de mogelijkheid om dit te verbieden voor diespecifieke hyperlink.

Ook als met kleurcoderingen of andere opmaakeigen-schappen gewerkt wordt om de terugconversie te sturen,dan kan niet voorkomen worden, dat de auteur degebruikelijke Word-functionaliteit gebruikt om dit tewijzigen. Niet zonder de Word-functionaliteit ingrijpendte wijzigen met een'plugin.Als verbogen codes worden opgenomen, om bijvoorbeeldattribuutinformatie te bewaren, dan kan niet voorko-men worden dat een auteur deze, onbewust, kan verwij-deren. In ieder geval niet als deze in de lopende tekstvoorkomen.

De praktijk

Het bovenstaande, theoretische verhaal is voortgevloeiduit de ervaringen die we in tal van projecten, waarinauteursprocessen centraal stonden, hebben opgedaan.We lichten er twee projecten uit waarin we nagenoegalle genoemde kenmerken en constateringen tegen zul-len komen. Het MCV2-project als voorbeeld van eengescheiden conversie en bewerking. En de WordShadowimplementatie als typisch voorbeeld van een geinte-greerde conversie. Beide voorbeelden hanteren met suc-ces RTF als tussenformaat om bewerking van XML/SGMLmet Word mogelijk te maken.Daarna komen ook de nieuwste ontwikkelingen vanMicrosoft op gebied van XML-ondersteuning aan deorde. Hiervoor wordt ingegaan op wat de (on)mogelijkhe-den zijn met Microsoft Word 2003.

Het MCV2-project

Bij Kluwer is een content management systeem ontwik-keld met een productiestraat en een workflow-systeemvoor creatie en beheer van SGML-documenten van ver-schillende uitgaven van Kluwer. Binnen het workflow-systeem wordt Word voor een deel van de uitgaven inge-zet als hulpmiddel voor de auteurs waarmee ze nieuwe

PAG

9

<!ELEMENTJAARGANG 10 • NR 2

RTF BewerkenOpslag

content kunnen aanmaken en bestaande content kun-nen bewerken. Voor het andere deel wordt, overigensook met succes, gebruikgemaakt van een auteurstoolgenaamd Styler (ontwikkeld door Mavim in opdracht vanKluwer).De Styler-applicatie is in feite voorbeeld van een geinte-greerde conversie en biedt invoeg- en bewerkfunctiona-liteit alsmede een op stijlenvolgorde gebaseerde contro-lefunctie. Deze applicatie is echter niet gebaseerd opWord en wordt daarom in het kader van dit artikel ver-der niet besproken.

De aanpak met Wordsjablonen is gebaseerd op eengescheiden conversie en bewerking. Het uitgangsfor-maat is SGML en als tussenformaat wordt RTF gehan-teerd. De auteurs zijn voorzien van een Wordsjabloonmet ondersteunende functionaliteit. Dit omvat invoeg-en bewerkfuncties, alsmede een stijlvolgorde controle-functie.Om alle informatie zo goed mogelijk te behouden bij deround-trip, is een forse list van stijlen gedefinieerd. Iedersoort kop en ieder teksttype heeft een eigen stijl. Verderworden zaken als voetnoten, tabellen en nadruk op eenzo natuurlijk mogelijke wijze in RTF weergegeven. Debetrokken DTD bevat echter ook vele typen verwijzingenen die worden niet vertaald. Ook kent de DTD in hogemate dieptestructuur, zowel buiten als binnen alinea's.Ook deze is moeilijk weer te geven in RTF. De terugverta-ling is dan ook geen eenvoudige klus. Bovendien gaateen belangrijke hoeveelheid (meta)informatie bij verta-ling naar RTF verloren en deze moet bij de terugconver-sie hersteld worden.

In figuur 5 ziet u een vereenvoudigd schema van hetworkflow-systeem. Alle voor dit artikel niet relevantezaken zijn hier weggelaten. Onder het schema volgt eenkorte toelichting bij de stappen van dit bewerkproces.De SGML-bestanden worden door een in Omnimark ont-wikkelde tool vertaald naar RTF. Hiervoor wordt eenzogeheten mappingbestand en een van hetWordsjabloon afgeleid RTF-template uitgelezen. Hetmappingbestand beschrijft hoe elementen naar stijlenvertaald moeten worden, het RTF-template bevat de defi-nities van de stijlen. Hiermee wordt volledig automa-tisch een SGML-bestand naar RTF vertaald.Dit RTF is gekoppeld aan het bedoelde Wordsjabloonwaarin DTD-specifieke functionaliteit is uitgewerkt. Debewerker kan het bestand openen in Word en de wijzi-gingen doorvoeren. Als de bewerker klaar is met zijntaak wordt het bestand opgeslagen als RTF. Dit resultaatin RTF wordt door een tweede, ook in Omnimark ont-wikkelde tool, vertaald naar SGML.

Om er voor te zorgen dat de alineaopmaakprofielen nietdoor elkaar gebruikt worden maar de structuur van deDTD volgen, is er gebruik gemaakt van een Word plugindie de volgorde van de gebruikte stijlen kan controlerenen aangeeft waar bepaalde delen toegevoegd mogenworden. Na bewerking kan met behulp van deze plugin,genaamd Programmar, de impliciete structuur van hetWord-bestand - de volgorde waarin de verschillende ali-neaopmaakprofielen voorkomen - gecontroleerd wor-den. De plugin werkt met een grammatica (BNF-notatie),die afgeleid is van de structuur van de gebruikte DTD. Indeze grammatica is op hierarchische vastgelegd in welke

Figuur 5: MCV2-Workflow in een notendop

PAG

10

<!ELEMENTJAARGANG 10 • OR 2

volgorde de alineaopmaakprofielen voor mogen komenin het Word bestand.Door een handige aanpak bij de terugconversie kandezelfde grammatica gebruikt worden voor de vertalingvan RTF naar SGML. Ook de mapping van elementennaar stijlen van de conversie van SGML naar RTF wordthergebruikt. Met deze informatie is de tweede conversie-tool in staat de oorspronkelijke SGML-structuur van debewerkte tekst in grote mate te herleiden.

Omdat bij vertaling van SGML naar RTF reeds structuur-informatie verloren is gegaan en de conversie van RTFnaar SGML geen gegarandeerd succes is, is een (semi-)handmatige nabewerking noodzakelijk. Met behulp vaneen geavanceerde compare-tool (speciaal hiervoor ontwik-keld door PlantijnCasparie) wordt op nauwkeurige wijzehet oorspronkelijke met het bewerkte SGML vergeleken.Verloren gegane verwijzingsmarkeringen, attributen enprocesinformatie worden daarbij hersteld. Dit levert eenSGML-bestand op dat in principe terug kan in de opslag.

Voordelen:n ook zonder gebruik van Wordsjabloon en plugin

bewerken mogelijk,n lage systeemeisen, door op RTF-gerichte ondersteu-

nende functionaliteit,n bulksgewijze conversie mogelijk.

Nadelen:n heen- en terugconversies alsmede Wordsjabloon

moeten goed op elkaar afgestemd zijn,n verlies van informatie, veroorzaakt door complexiteit

van DTD,n beperkte auteursondersteunende functionaliteit en

alleen stijlvolgorde controle,n bewerkelijke nabehandeling om verloren informatie

te herstellen.

WordShadow

Nog voor aanvang van het MCV2-project is gewerkt aaneen Word-plugin, uitgewerkt in Visual Basic, die hetmogelijk maakt om XML (of SGML) `rechtstreeks' te ope-nen, bewerken en opslaan met Word, maar die de inter-face en de werking van Word hierbij zoveel mogelijkintact laat. Dit is dus een voorbeeld van een oplossingmet een geintegreerde conversie.

De eerste implementatie ervan voerde reeds een verta-ling naar RTF uit voor het inlezen, maar benutte hetobjectmodel voor het vertalen naar XML/SGML. Voor degebruikers was een validatiefunctie beschikbaar gesteld,die vergelijkbaar aan de Programmar-tool stijlvolgordesop basis van een soort grammatica (in feite uitgewerktals een DTD!) kon controleren.In een later stadium is gekozen om ook voor de verta-ling naar XML/SGML een route via RTF te kiezen omdatde functionaliteit die Word biedt om het objectmodeluit te lezen te beperkt is. Alleen voor de validatiefunctieis om performanceredenen gekozen via het objectmodelte blijven werken. Het verschil is echter dat vanaf dezeversie de validatie uitgevoerd wordt tegen de volledige

DTD van het XML- of SGML-formaat en niet meer tegeneen afgeleide definitie (vergelijk MCV2).

Met het XML/SGML-conversieresultaat binnen handbe-reik is het niet moeilijk om ook deze vanuit Word voorde gebruiker toegankelijk te maken in de vorm van eenXML/SGML-Structuurvenster, waarin bewerkingen uitge-voerd kunnen worden. De overige functionaliteit iszoveel mogelijk eenvoudig en generiek gehouden enbestaat, naast allerlei van Word geleende functies, voor-namelijk uit een zogeheten Stijlenmenu waarin de tegebruiken stijlen min of meer in toegestane volgordeopgesomd worden.

Voor de vertaling van XML/SGML naar RTF (het importe-ren) wordt, vergelijkbaar aan het MCV2-verhaal, gebruik-gemaakt van een mappingbestand en een RTF-template.Qua conversies is het verhaal dan ook niet veel andersdan bij MCV2. De gekozen techniek waarin de conversieuit wordt gevoerd is echter geheel anders, namelijkMetaMorphosis, een boomgeorienteerde programmeertaal(met een soort van W3C DOM-objecten), waar Omnimarkjuist Stream-geOrienteerd is (min of meer het W3C SAX-model). Ook hierbij geldt dat informatie reeds bij verta-ling van XML/SGML naar RTF verloren gaat.

De vertaling van RTF naar XML/SGML (het exporteren) iszoals reeds gezegd een ingewikkeld verhaal. De ontwik-keling van de applicatie heeft niet hetzelfde niveaubereikt als de tool van de equivalente stap in MCV2. Ditzorgt ervoor dat het uitwerken van de exportfunctie vanWordShadow voor een nieuwe DTD relatief arbeidsinten-sief is en veel kennis van de taal MetaMorphosis vereist.Deze applicatie is met succes ingezet in projecten waar-in documenten met een redelijk eenduidige en niet al tediepe alineastructuur, zodat vrijwel alle oorspronkelijkestructuurinformatie te herleiden is uit het RTF. Dit voor-komt dat een handmatige nabewerking noodzakelijk is.

Voordelen:n geintegreerde conversie brengt eindresultaat binnen

handbereik van auteur,n ondersteunende functionaliteit kan bier op toege-

spitst warden,n en daardoor zeer geschikt voor kleinschalige projec-

ten en/of minder complexe DTD's.

Nadelen:n vereist (iets zwaardere) installatie,n hogere systeemeisen,n minder geschikt voor al te complexe DTD's, omdat

de beperkingen van RTF nabewerking soms noodza-kelijk maken,

n het gebruik van de taal MetaMorphosis voor de con-versie, waarvan de ontwikkeling sinds 2002 gediscon-tinueerd is.

Microsoft Word 2003

De komst van Word 2003 brengt nieuwe mogelijkhedenmet zich mee en vereenvoudigt een aantal zaken.Word 2003 biedt ingebouwde XML-functionaliteit (SGML

PAG

11

<!ELEMENT1PARGANG 10 • Nil

wordt niet ondersteund). Conversie van en naar XML iseenvoudig, want Word 2003 kan XML rechtstreeks inle-zen en wegschrijven, hetgeen (onnodig) verlies van infor-matie voorkomt. Ook staan op XML gerichte middelenvoor het afdwingen van structuur ter beschikking. Word2003 kan een continue validatie tegen een of meer sche-ma's uitvoeren (geen DTD-ondersteuning helaas) eneventuele fouten presenteren op een manier die verge-lijkbaar is met de manier waarop spellingsfouten weer-gegeven worden. Een XML-structuurweergave is stan-daard beschikbaar en ook het objectmodel, waarover inhet begin kort is gesproken, is uitgebreid met toegangtot de XML-structuur (min of meer) conform W3C DOM-standaard. Ook is het mogelijk om op enkele momentenop eenvoudige wijze een XSL-conversie te laten uitvoe-ren, bijvoorbeeld bij het openen van een bestand of bijhet opslaan.

Deze nieuwe features zorgen ervoor dat Word eenvoudi-ger ingezet kan worden als XML-auteurstool. Conversienaar een tussenformaat is niet nodig en het uitwerkenvan auteursondersteunende functionaliteit is door debeschikbaarheid van het XML-document en ingebouwdeXML-functionaliteit eenvoudiger.Daarnaast zijn nieuwe features toegevoegd zoals eenconcept genaamd Expansion Packs waarmee gebruikerszelf uitbreidingen voor Word kunnen installeren, active-ren en updaten. Ook is het gebruikersinterface uitge-breid met een zogeheten Task Pane waarin ruimte gere-serveerd is om document- (en dus schema)-afhankelijkefunctionaliteit beschikbaar te stellen. Dit is de zogehe-ten Smart Document-functionaliteit. Dit maakt verfraaiingvan de auteurstool erg eenvoudig.

Op het eerste oog lijkt hiermee het bewerken van XMLwerkelijk binnen handbereik van reguliere Word-gebrui-kers te komen. Echter, zoals al bij het onderwerpIntegratie met Word' aan bod is gekomen, vereist XML-functionaliteit enige XML-vaardigheid of -begrip van degebruiker. En het uitgangspunt was juist, dat auteursdeze niet hoeven te hebben. Een deel van de gebruikersvan WordShadow gaf aan dat enige XML/SGML gerela-teerde informatie, zoals een structuurweergave doorhen gewaardeerd werd, maar dat het afbreuk doet aande auteurstool als dit de reguliere werlcwijze in Word -namelijk het bewerken van de tekst - beinvloedt. Denkaan de genoemde opmerkingen over attribuutbewerkingen het maken van selecties.

Helaas is de geboden XML-functionaliteit nog nietgeheel volwaardig en uitsluitend beschikbaar als eenXML-document geopend wordt en niet bij het openenvan een afgeleide representatie zoals een RTF-document.Daarnaast gelden zware systeemeisen voor Word 2003en dient minimaal de Professional Edition geinstalleerdte worden om de volledige XML-functionaliteit terbeschikking te hebben. De te verwachten installed-basevoor deze versie zal daarom sterk kleiner zijn dan dehuidige. En ondanks alle moeite die Microsoft in deXML-ondersteuning heeft gestoken, zijn ze vergeten nate denken over een dynamische koppeling tussen XML-

structuur en opmaak, zoals in een Cascading Styles Sheet(alleen ondersteund in Word voor HTML-documenten).

Toch biedt Word 2003 nog een interessante mogelijk-heid. Alle overige oplossingen worstelen met het pro-bleem om XML/SGML om te zetten in een voor Wordleesbaar formaat. Met Word 2003 is dat specifieke deelniet meer nodig. Word 2003 kan zonder problemen XMLinlezen en opslaan als RTF of Word-doc, al dan nietgeconverteerd met behulp van een XSL-stylesheet. Ookkan een Word-document in een Microsoft XML-formaatweggeschreven worden: WordML. Dit kan een goed jump-start vormen voor conversie van Word-documenten naarXML/SGML.

Voordelen:n potentieel geen verlies meer van informatie,n conversie naar tussenformaat overbodig,n ingebouwde XML-gerichte functionaliteit, zoals vali-

datie en XML-structuurweergave,n eenvoudig updatemechanisme (Expansion Packs),n nieuwe gebruikersinterface mogelijkheden (onder

andere Smart Documents en Task Pane).

Nadelen:n zware systeemeisen en installatie,n hoge licentiekosten (minimaal Professional Edition

vereist),n XML wordt als XML gepresenteerd en moet op XML

manier bewerkt worden,n XML-bewerkfunctionaliteit is niet volwaardig (bepaal-

de acties niet mogelijk),n dynamische koppeling opmaak en XML-structuur

ontbreekt, hetgeen out-of-the-box gebruik als auteur-stool in de weg start.

ConclusieWord kan worden ingezet om het bewerken vanXML/SGML-informatie voor auteurs met beperkte of geenXML/SGML-kennis mogelijk te maken, zonder dat ditaansluiting op geautomatiseerde workflow-systemen inde weg hoeft te staan.Dit betekent echter dat de XMLISGML-bestanden vertaaldmoeten worden naar een formaat dat Word in kanlezen, uitgezonderd voor Word versie 2003 en eventueletoekomstige versies. RTF is hiervoor naar onze meninghet meest geschikte tussenformaat. Door ondersteunen-de functionaliteit in Word in te bouwen, kan het bewer-ken door de auteur gestroomlijnd en aansluiting op deworkflow gegarandeerd worden.

Deze functionaliteit kan in meerdere gradaties geinte-greerd worden met Word:n Geen ondersteunende functionaliteit aanbieden en

alleen een conversie van en naar het tussenformaathanteren is de goedkoopste oplossing. Dit vergt ech-ter veel discipline van de auteurs.

n Dit aanvullen met een Wordsjabloon met beperktefunctionaliteit, is een relatief goedkope uitbreidingdie, athankelijk van de geboden functionaliteit, deeisen aan discipline en nauwgezetheid sterk kan ver-

JAARGANG 10 • NR 2<!ELEMENT

lagen. De geboden functionaliteit beperkt zich ech-ter noodzakelijkerwijs tot het tussenformaat (bijvoor-beeld geen validatie tegen DTD). Beter geschikt voorgrote groepen en/of sterk wisselende auteurs, vanwe-ge beperkte uitrol. Zie ook het praktijkvoorbeeldMCV2.

n Integratie van de conversie in Word, maakt hetmogelijk de auteur veel meer functionaliteit te bie-den, zoals op XML/SGML gebaseerde zoek-, bewerk- enpreview-functies en op DTD gebaseerde validatie.Brengt hogere systeemeisen en zwaardere uitrol metzich mee. Licentiekosten spelen ook een belangrijkerol. Zeer geschikt voor kleinschaligere projecten. Ziehet praktijkvoorbeeld WordShadow.

n Inzet van Word 2003, waarbij integratie niet meernodig zou zijn, valt in feite of door de zware systeem-eisen en de hoge licentiekosten. Out-of-the-box is hetwel bruikbaar, maar niet auteursvriendelijk.

Het gebruik van RTF als tussenformaat brengt complica-ties met zich mee. Deze omvatten problemen met hetround-trippen van informatie, de DTD-afhankelijkheid vanhet tussenformaat en de conversie, het ontbreken vandieptestructuur in RTF, ingewikkelde tabelnotatie inRTF, de beperkte structuur binnen alinea's en de beperk-te mogelijkheden van bescherming tegen ongewenstebewerkingen. Op verschillende van deze punten zijn metredelijk succes oplossingen uitgewerkt. Verarming vande structuur bij round -trippen is echter zo goed als onver-mijdelijk en de vraag is in hoeverre hierin compromis-sen gemaakt kunnen worden.

Als antwoord op de vraag: "Is Microsoft Word geschikt als

XML/SGML auteursomgeving?" geven wij het volgende mee.Met name de integratie van de conversie in een auteurs-hulpmiddel vergroot de potentie van de auteurstool inhoge mate. Het gevarieerde aanbod van ondersteunendefunctionaliteit van het voorbeeld WordShadow toont dithopelijk aan. De nadruk ligt echter op potentie, wantniet alle auteurstools die verder op de markt te vindenzijn (al dan niet Word-gebaseerd), benutten deze poten-tie ten voile. De meesten slechts ten dele. Dit is dan ook

wat wij als een belangrijk beoordelingscriterium vooreen auteurshulpmiddel beschouwen.De geintegreerde oplossing is zeer geschikt voor klein-tot middelschalige inzet bij auteurs en als gebruikers-vriendelijke applicatie bij de redactie. Bij grootschalige-re inzet (denk aan 100 of meer gebruikers), gaan uitrolen onderhoud duidelijk een overwegende rol spelen. Indie situaties kan geld bespaard worden door voor niet-geintegreerde oplossingen te kiezen.

Wellicht valt op dat web-applicaties geheel nietgenoemd zijn in dit verhaal, hoewel deze vanuit licentie-en onderhoudsoogpunt zeer interessant zijn. Eenbelangrijk nadeel aan auteurshulpmiddelen met eenweb-interface is echter, dat deze nog veel beperkenderzijn dan het gebruik van het RTF-tussenformaat.Uitgezonderd de situatie waarin er voor gekozen wordtom via het web-interface toch weer een (thin-client) XML-editor aan te bieden. Wellicht dat in een toekomstig arti-kel in <!ELEMENT nader op deze applicaties en demanier waarop ze in auteursomgevingen kunnen wor-den ingezet, kan worden ingegaan.

Meer informatie

n Voor meer over het gebruik van Word processors omSGML te bewerken: http://heim.ifi.uio.norpaalso/artikler/styles/new-version/pap.html.

n Voor een gedetailleerd overzicht van vele beschikba-re auteurstools: "Onderzoeksrapport Auteurs- enRedactietools" te vinden op http: //www.daidalos.nl/area.webview?area=publicaties.

n Voor meer over Microsoft Word, zie:http://www.microsoft.com/office/word/.

n Voor meer over RTF, zie: http://msdn.microsoft.com/library/default.asp?ur1=/library/en-us/dnrtfspec/html/rtfspec.aspen ook: http://interglacial.com/rtfi.

n Voor meer over Office 2003, zie: First Look Microsoft

Office 2003, Katherine Murray, Microsoft Press, 2003.(Waarschijnlijk zijn bij het verschijnen van dit artikelrecentere boeken verkrijgbaar.): http://www.micro-soft.com/office/VVord/prodinfo/default.mspx.

111 Geert Josten en Peter Kester (Daidalos) staan

bekend als conversie- en contentspecialisten. Beiden hebben

ruime kennis en ervaring op het gebied van conversietalen

zoals Omnimark en MetaMorphosis, als ook XML-gerela-teerde standaarden als XSL en de hierop gebaseerde conver-

sieoplossingen die in dit artikel aan de orde zijn gekomen.s n

JAARGANG 10 • NR 2<!ELEMENT