Vælge en XML Schema: DocBook eller Dita ?

Richard Hamilton har fremlagt et tankevækkende analysen af, hvornår at vælge DocBook eller Dita, offentliggjort på Content Wrangler blog her: http://www.thecontentwrangler.com/article_comments/ choosing_an_xml_schema_docbook_or_dita/

Jeg begyndte at skrive følgende som en kommentar til denne post, men det har længe nok, at jeg troede det bedre at skrive min fulde svar her.

Jeg generelt er enig med Richard's analysen så vidt det går, men jeg synes, det miss flere vigtige punkter, som jeg hævde tip skalaerne betydeligt til fordel for Dita over DocBook.

Hvis du leder efter en dokumentation skema, som du kan bare samle op og bruge, og du behøver ikke at modularitet træk ved Dita (det vil sige, at du ikke behøver funktionaliteten af Dita kort) derefter DocBook formentlig passer bedst til de grunde, Richard nævner, nemlig at der er flere element typer sandsynligt nytteværdi ud af æsken og forarbejdning infrastruktur er mere modne og bedre dokumenteret.

Men hvis du ved, du har brug for at tilføje markup for dine specifikke krav eller er ved at udvikle et nyt XML-program, hvor ting som markup skræddersyet til lokale brugere eller krav er vigtigt eller modularitet er vigtigt, derefter Dita har en meget klar fordel, fordi det er så meget lettere at udvikle og udvide brugerdefinerede dokumenttyper fra en Dita base end fra en DocBook base.

?sagen er meget enkel: Dita's specialisering mekanisme, kombineret med den erklæring, der design mønstre defineret af Dita arkitektur, gøre det så let, som det kunne eventuelt være at udvikle nye markup strukturer. Især har defineret specialer, kan du blive nødt til at gøre noget mere for at have dokumenter, der bruger disse nye typer arbejde med eksisterende Dita processorer, redaktører, CMS systemer osv.

DocBook kan ikke have denne egenskab, indtil så længe det enten vedtager Dita specialisering mekanisme (som det kunne let gøre - jeg har arbejdet hårdt for at få den specialisering aspekter af Dita defineres som adskiller sig fra de Dita element typer specifikt, så det kunne overtages af andre XML-programmer med et minimum af balladen) eller tilføjer den tilsvarende funktionalitet ved at bruge nogle andre syntaks [en begrænsning i den nuværende Dita specialisering mekanisme er ikke nogen god måde at støtte namespaced elementer - at der vil blive fastsat i Dita 2,0 men ingen er endnu ikke begyndt at arbejde seriøst på det, at kunne være - dette kan være en mulighed for DocBook at tage føringen, da DocBook afgjort har en namespace krav.]

med nogen DocBook ansøgning, hvis du definere et nyt element typer, der ikke er defineret måde at map dem tilbage til de eksisterende typer og DocBook processorer er ikke konstrueret til at håndtere nye typer af behandling af dem i form af nogle base type. Det betyder, at hvis du definere et nyt element typer i en DocBook forbindelse skal du opdatere alle processorer, der er nødt til at handle med de pågældende dokumenter, selvom alt, hvad de skal gøre, er ikke noget med disse elementer.

På genstand for beskrivende dokumenter, der er grundlæggende ingen praktisk forskel mellem Dita og DocBook i deres evne til at støtte oprettelsen af ?instans dokumenter af vilkårlig dybde. Dette er indlysende for DocBook (fordi det er, hvad det var beregnet til), ikke så indlysende for Dita (fordi det var konstrueret til det modsatte).

Men med Dita alt, hvad du skal gøre, er at opsætte din lokale doctypes ( "skaller" i Dita parlance) at give emner til reden. For eksempel er det enkleste tilfælde er simpelthen at tillade generiske emne for at teste. Med, at du kan repræsentere en eventuel fortælling dokument strukturelt.

Den eneste meningsfuld forskel i dette scenario mellem Dita og DocBook er, at Dita kræver kroppen af en sektion til at blive pakket i en container (emnet organ) , Mens DocBook ikke giver en sådan container (eller i det mindste ikke sidste gang jeg kiggede).

Det er virkelig en bagatel forskel.

For flere kunder, der gør udgivelse snarere end tekniske dokumentation, jeg har udviklet trivielle specialer, som giver generiske emner adskilles kun af deres emne type navne, men bruger ellers generiske Dita elementer for indhold. Jeg plejer at definere et specialiseret emne kaldet "underafdeling", der kan rede til en hvilken som helst dybde. Med denne model kan du repræsentere dokumenter såvel som eller bedre end du kan med DocBook og du får alle de andre Dita godhed som godt.

Endelig er der en gratis Dita-til-DocBook transformere, der er del af den frie Dita Open Toolkit, der giver dig mulighed for at bruge alle de DocBook forarbejdning infrastruktur med Dita-baseret indhold. Dette bruges for eksempel til at anvende ikke-Dita-klar sammensætning systemer som XPP med Dita-baseret indhold.

Fordi Dita tilbyder en række meget vigtige funktioner, der DocBook ikke, især specialisering, modularitet, og eksterne links (forholdet tabeller), og fordi Dita kan konfigureres til at arbejde såvel for ikke-modulære dokumenter som DocBook kan, og fordi Dita sænker omkostningerne ved at udvikle nye element typer så lavt, som det kunne måske være, jeg ' ve kommet til den konklusion, at Dita er det bedste svar til enhver XML-baserede dokument-centreret ansøgning jeg har set.

Bare det faktum, at du kan få OxygenXML for næsten ingenting, definere en helt ny Dita specialisering , Installere det på din lokale Toolkit som et plugin (en meget nem betjening, når du ved, hvad de skal gøre, hvilket jeg er nødt til at skrive en tutorial til), du kan derefter redigere dokumenter, der benytter denne specialisering i en alle funktioner grafisk, tags off redaktør uden ekstra arbejde af enhver slags er ret magtfulde. DocBook kan ganske enkelt ikke muligt, at fordi det ikke har Dita's specialisering funktion.

Hvis DocBook vedtaget Dita's specialisering mekanismer, så denne diskussion vil ikke engang være meningsfyldt, fordi DocBook ville få al den værdi, specialisering tilfalder Dita og ville stadig have værdien af at være et begrebsmæssigt mere enkel model for dokumenter.

hvilket rejser spørgsmålet: hvorfor ikke DocBook blot vedtage Dita's specialisering mekanisme? Det ville koste DocBook næsten ikke noget at tilføje og tilføje enorm værdi. Det ville ikke kræve DocBook at ændre noget ved den nuværende markup design, undtagen for eventuelt at back-form nogle base typer, der i øjeblikket ikke udtrykkeligt i DocBook men ville være nyttigt som en specialisering base. Men det vil kun gøre DocBook renere .