XML-versioner. Tio XML-regler du behöver känna till
Standarden definierar två nivåer av XML-dokumentets giltighet:
- Välbyggd(Välformad). Ett välformaterat dokument matchar alla generella regler XML-syntax som är tillämplig på alla XML-dokument. Och om till exempel starttaggen inte har en motsvarande sluttagg, då detta felaktigt konstruerad XML-dokument. Ett dokument som inte är välformaterat kan inte betraktas som ett XML-dokument; En XML-processor (parser) ska inte behandla den på vanligt sätt och är skyldig att klassificera situationen som ett fatalt fel.
- Giltig(Giltig). En giltig handling motsvarar dessutom några semantiska regler... Detta är en strängare ytterligare kontroll av ett dokuments korrekthet för att följa förutbestämda, men redan externa regler, för att minimera antalet fel, till exempel strukturen och sammansättningen av ett visst dokument eller en familj av dokument. Dessa regler kan utvecklas antingen av användaren själv eller tredjepartsutvecklare, till exempel av utvecklare av vokabulärer eller standarder för datautbyte. Vanligtvis lagras sådana regler i specialfiler- system där de flesta i detalj beskriver strukturen på dokumentet, alla tillåtna namn på element, attribut och mycket mer. Och om ett dokument, till exempel, innehåller ett elementnamn som inte är fördefinierat i scheman, övervägs XML-dokumentet ogiltig; den validerande XML-processorn (validatorn), när den kontrollerar efterlevnad av regler och scheman, är skyldig (efter användarens val) att rapportera ett fel.
Dessa två begrepp har inte en tillräckligt väletablerad standardiserad översättning till ryska, särskilt begreppet giltig som också kan översättas som giltig, legitim, pålitlig, passa, eller ens testad för överensstämmelse med regler, standarder, lagar... Vissa programmerare använder det väletablerade spårpappret i vardagen" Validny».
XML-syntax
Detta avsnitt behandlar endast korrekt konstruktion XML-dokument, det vill säga deras syntax.
XML är en hierarkisk struktur utformad för att lagra alla data; visuellt kan strukturen representeras som ett träd. Det viktigaste obligatoriska syntaktiska kravet är att dokumentet endast har en rotelement(rotelement) (kallas alternativt dokumentelement). Detta innebär att texten eller andra uppgifter i hela dokumentet måste placeras mellan den enda en startrottagg och dess motsvarande sluttagg.
Nästa enklaste exemplet- välformaterad XML-dokument:
En kommentar kan placeras var som helst i trädet. XML-kommentarer placeras i ett par taggar
... De två bindestrecket (-) kan inte användas någonstans i en kommentar.
Nedan är ett exempel på en enkel kulinariskt recept märkt med XML:
Strukturera
Resten av detta XML-dokument består av kapslade element varav några har attribut och innehåll. Element består vanligtvis av start- och sluttaggar som ramar in text och andra element. Öppnande tag består av elementnamnet inom vinkelparenteser, till exempel "
I exemplet ovan har elementet "ingrediens" två attribut: "amount", som har värdet "3", och "enhet", som har värdet "glas". Ur synvinkel XML-uppmärkning är de givna attributen inte meningsfulla, utan är bara en uppsättning tecken.
Förutom text kan ett element innehålla andra element:
V det här fallet elementet "Instruktioner" innehåller tre "steg"-element. XML tillåter inte överlappande element. Till exempel är kodavsnittet nedan felaktigt eftersom elementen "em" och "stark" överlappar varandra.
Vanligt accentuerad framhävd och accentuerad tillägnad
Varje XML-dokument måste innehålla exakt ett rotelement(rotelement eller dokumentelement), så följande kodavsnitt kan inte betraktas som ett giltigt XML-dokument.
För att beteckna ett element utan innehåll kallas tomt element, nödvändig använd en speciell form av post, bestående av en tagg, där ett snedstreck placeras efter elementnamnet. Om ett element inte deklareras tomt i DTD, men det inte har något innehåll i dokumentet, för det tillåten tillämpa denna form av anmälan. Till exempel:
XML definierar två skrivmetoder speciella karaktärer: enhetsreferens och referens efter symbolnummer. Kärnan(entitet) i XML benämns data, vanligtvis textmässiga, i synnerhet specialtecken. Enhetsreferens(entitetsreferenser) specificeras där entiteten ska vara och består av ett og-tecken ("&"), namnet på entiteten och ett semikolon (";"). XML har flera fördefinierade entiteter som "lt" (du kan referera till det genom att skriva "< ») для левой угловой скобки и « amp » (ссылка - « & ») для амперсанда, возможно также определять собственные сущности. Помимо записи с помощью сущностей отдельных символов, их можно использовать для записи часто встречающихся текстовых блоков. Ниже приведён пример использования предопределённой сущности для избежания использования знака амперсанда в названии:
Den fullständiga listan över fördefinierade enheter består av & ("&"),< («<»), >(">"), "(" "") och "(" "") - de två sista är användbara för att skriva avgränsare inom attributvärden. Du kan definiera dina entiteter i DTD-dokumentet.
Ibland är det nödvändigt att definiera icke-brytande utrymme, som mycket ofta används i HTML och betecknas som det inte finns någon sådan fördefinierad enhet i XML, den skrivs och dess användning ger upphov till ett fel. Avsaknaden av denna mycket vanliga essens för många programmerare är ofta förvånande och detta skapar vissa svårigheter när de migrerar sin HTML-utveckling till XML.
Referens med symbolnummer Den (numeriska teckenreferensen) ser ut som en enhetsreferens, men istället för enhetsnamnet anges tecknet # och ett tal (i decimal eller hexadecimal notation) som är teckennumret i Unicode-kodtabellen. Dessa är vanligtvis tecken som inte kan kodas direkt, till exempel en arabisk bokstav i ett ASCII-kodat dokument. Et-tecken kan representeras enligt följande:
Det finns många fler regler om hur man skriver ett välformaterat XML-dokument, men syftet med detta kort överblick var bara för att visa grunderna som behövs för att förstå strukturen i ett XML-dokument.
Historia
Födelseåret för XML kan anses vara 1996, i slutet av vilket utkastet till språkspecifikationen dök upp, eller när denna specifikation godkändes. Allt började med uppkomsten av SGML-språket 1986.
SGML (Standard Generalized Markup Language) har etablerat sig som ett flexibelt, komplext och allomfattande metaspråk för att skapa märkningsspråk. Trots att begreppet hypertext dök upp 1965 (och de bakomliggande principerna formulerades 1945) har SGML ingen hypertextmodell. Skapandet av SGML kan säkert kallas ett försök att förstå det oändliga, eftersom det kombinerar funktioner som extremt sällan används tillsammans. Detta är dess största nackdel - komplexiteten och, som ett resultat, den höga kostnaden för detta språk begränsar dess användning endast av stora företag som har råd att köpa motsvarande programvara och anlita högbetalda specialister. Dessutom har små företag sällan så komplexa problem att de involverar SGML i sin lösning.
SGML används mest för att skapa andra märkningsspråk; det var med dess hjälp som märkningsspråket för hypertextdokument - HTML, skapades, vars specifikation godkändes 1992. Dess utseende var förknippat med behovet av att organisera ett snabbt växande utbud av dokument på Internet. Den snabba tillväxten av antalet internetanslutningar och följaktligen webbservrar har lett till ett sådant behov av kodning elektroniska dokument som SGML inte kunde hantera på grund av sin höga inlärningskurva. Framväxten av HTML är mycket enkelt språk uppmärkning - löste snabbt detta problem: dess enkla inlärning och rikedom av dokumentförberedande verktyg gjorde det till det mest populära språket för internetanvändare. Men i takt med att antalet och kvaliteten på dokument på webben ökade, ökade kraven på dem, och HTMLs enkelhet blev dess största nackdel. Det begränsade antalet taggar och fullständiga likgiltighet för dokumentets struktur fick utvecklarna i W3C-konsortiets person att skapa ett märkningsspråk som inte var lika komplext som SGML och inte lika primitivt som HTML. Som ett resultat föddes XML, som kombinerar enkelheten i HTML med logiken i SGML-märkning och möter kraven från Internet.
Fördelar och nackdelar
Fördelar
nackdelar
- Otydlighet i modellering.
- XML innehåller inte stöd för modersmål för datatyper. Den har inte stark typning, det vill säga begreppen "heltal", "strängar", "datum", "booleaner" etc.
- Den hierarkiska datamodellen som erbjuds av XML är begränsad jämfört med relationsmodellen och objektorienterade grafer, och nätverksmodell data.
Visar XML på World Wide Web
Det finns tre vanligaste sätten att konvertera ett XML-dokument till en användarsynlig vy:
- Tillämpa CSS-stilar;
- Tillämpa en XSLT-transformation;
- Skriva en XML-dokumentbehandlare i ett programmeringsspråk.
Utan använder CSS eller XSL XML-dokument visas som vanlig text i de flesta webbläsare. Vissa webbläsare som Internet Explorer, Mozilla och Mozilla Firefox visar dokumentstrukturen som ett träd, så att du kan komprimera och expandera noder med musklick.
Tillämpa CSS-stilar
Processen liknar att tillämpa CSS på ett HTML-dokument för visning.
För tillämpa CSS när det visas i en webbläsare måste XML-dokumentet innehålla en speciell länk till stilmallen. Till exempel:
Detta skiljer sig från HTML-metoden där elementet används .
Tillämpa en XSLT-transformation
XSL är en teknik som beskriver hur man formaterar eller transformerar data i ett XML-dokument. Dokumentet omvandlas till ett format som lämpar sig för visning i en webbläsare. Webbläsaren är mest frekvent användning XSL, men kom ihåg att XSL kan användas för att transformera XML till vilket format som helst, till exempel
För att automatiskt omvandla innehållet i xml-filer till en läsbar form/format (html, rtf, pdf, txt, vrml, svg, java, etc.), bör du använda XSLT istället för att försöka använda CSS.
Nackdelar med CSS:
1. CSS kan inte ändra ordningen på elementen i xml-dokumentet. Om du vill sortera några element eller filtrera dem efter någon egenskap, så kommer CSS definitivt inte att hjälpa dig med detta.
2. CSS utför inte beräkningar. Om du vill beräkna och mata ut värdet (till exempel summa numeriska värden alla element i xml-dokumentet), kommer CSS inte att fungera för dig.
3. CSS kan inte slå samman dokument. Om du vill kombinera ett par dussin xml-dokument med inköpsorder och skriva ut en sammanfattning av alla beställda varor, så kommer CSS inte att hjälpa dig igen.
Litet exempel på att använda XSL
Det finns några xml-fil för plugininställningar:
Insticksprogrammet styr inställningarna för lagren av AutoCAD-ritningar. Nedan finns en tabell som listar de artiklar som ska kontrolleras.
Kontrollerar lagrets namn
Sann
Kontrollerar lagernamnet för överensstämmelse med namnregeln
Kontrollera färgen på ett lager
Sann
Kontrollera att lagret tilldelas färger från paletten "Indexfärg".
Kontrollera linjetypen
Sann
Kontrollera att lager endast tilldelas linjetyper från en specifik uppsättning
Kontrollera linjevikter
Sann
Kontrollera att lager endast tilldelas linjetjocklek från en specifik uppsättning
Kontrollerar om det finns en kommentar
Sann
Varje lager bör ha en anteckning som tyder dess syfte.
Fast uppsättning lager
falsk
Bör användare förbjudas att skapa ytterligare lager enligt reglerna i standarden?
Insticksprogrammet bör läsa inställningarna från det och fungera i enlighet med dem. Samtidigt bör det finnas en del dokumentation som användaren kan läsa och förstå. Dessutom måste materialet som presenteras i dokumentationen överensstämma med de inställningar som för närvarande är installerade. För att inte komma ihåg att efter att ha justerat inställningarna måste du klättra och redigera dokumentationen, du kan presentera allt detta i form av en xml-fil. Insticksprogrammet kommer att läsa inställningarna från det, och användaren kommer att öppna det i en webbläsare och ... se det i en "mänsklig" form ... För att göra detta, skapa en styleSheet.xsl-fil med följande innehåll:
Plugin-inställningar
Parameter Värde Obs
Nu, om en användare öppnar vår xml-fil i webbläsaren, kommer han att se inte förvirrande (ur hans synvinkel), obekväm xml-text, men denna:
V detta exempel Jag visade inte urval, sortering, filtrering, olika operationer och beräkningar (de behövdes inte här), men vid behov kan allt detta göras med XSLT.
5 svar
Det ditt hjärta säger till dig är korrekt. Även om det är möjligt att använda CSS för XML, har XML i sig ingen semantik. CSS är för webben, för HTML och för att tillhandahålla (bra) semantisk data.
XML är mer allmänt än så. XSLT uppfanns för att omvandla ett dataformat till ett annat (endast XSLT 1.0 XML, XSLT 2.0 vilket Unicode-dataformat som helst), dvs XML till HTML eller XML till XSL-FO eller annat XML-format eller text. XSL-FO uppfanns för att placera XML på papper eller skärm och är mycket mer omfattande än CSS.
Vissa för- och nackdelar i CSS + XML
Mestadels nackdelar, speciellt. mot bakgrund av användningen av XML i webbläsaren. Hoppa över det allmänna tipset nedan om du inte vill ha allt mitt prat; -)
CSS minus 1: ingen CSS + XML för webben
Nackdelar: Detta är mycket kontextberoende, men om du vill använda XML för visning på webben, tänk om: använd inte XML, konvertera det till HTML. Använd sedan CSS + HTML för att rendera dina data. Om du använder XML på webben, nej sökmotor eller en sökare, förstår inte skillnaden mellan och
.
Detta i sig är skäl nog att använda XSLT för att transformera till HTML + CSS och utesluta XML själv.
CSS nackdelar 2: CSS innebär mycket mer arbete
En annan extremt viktig anledning du kan använda: XML + CSS innebär att definiera varje element i CSS. Att använda HTML + CSS innebär att användaragenter redan känner till standardlayoutegenskaperna för alla element. Att använda XML + XSLT innebär att du vanligtvis skapar HTML + CSS. Du måste göra detta på serversidan eftersom XSLT på klientsidan inte är särskilt tillförlitlig och kompatibel med flera webbläsare.
CSS nackdelar 3: tillgänglighet
(förlåt att jag inte kan hitta ett proffs). Om XML inte har någon semantik (SVG som nämnts av en annan användare) är det ingen idé att använda CSS för layouten. Om layouten förmodas förstås semantiskt av användaragenten, fungerar inte XML + CSS. Att läsa text till tal har ingen aning om vad man ska göra, WAI-giltighet (tillgänglighet) kommer inte att vara möjlig osv.
CSS nackdelar 4: underhållbarhet, förståelighet, skript, problem
Att använda XML gör alla skript på klientsidan svåra att utföra (ja, DOM är tillgängligt, men hur berättar du för webbläsaren vad en skripttagg är?