Αυτό το Tutorial είναι σχεδιασμένο σαν εισαγωγή στη δημιουργία valid XML έγγραφων. Το Tutorial για well formed XML είναι καλή προϋπόθεση για αυτό το tutorial, αφού όλα τα έγγραφα XML, well formed και valid, πρέπει να είναι τουλάχιστον well formed. Χρησιμοποιώντας αυτό το tutorial, θα μάθετε πώς να γράφετε valid XML, και να δημιουργήσετε έγγραφα valid XML. Αν μπερδευτείτε, κοιτάξτε τα παραδείγματα που βρίσκονται σε αυτό το tutorial ή κάντε μια ανασκόπηση στο tutorial για well formed XML.
Η βασική διαφορά μεταξύ της valid και well formed XML είναι η σχέση τους με το DTD(Document Type Definition, Ορισμός Τύπου Εγγράφου). Η well formed XML είναι σχεδιασμένη για χρήση χωρίς DTD, ενώ η valid XML ρητά απαιτεί χρήση DTD. Ένα DTD είναι ένα σετ κανόνων που ένα έγγραφο ακολουθεί, και τους οποίους το software μπορεί να πρέπει να διαβάσει προτού επεξεργαστεί και εμφανίσει το έγγραφο. Αυτοί οι κανόνες γενικά καθορίζουν το όνομα και το περιεχόμενο κάθε στοιχείο (element) από τα οποία το απόσπασμα μπορεί και πρέπει να αποτελείται. Το στοιχείο παράγραφος μπορεί να οριστεί ότι περιέχει στοιχείο λέξη κλειδί (elements keyword), και κώδικα και ότι υπάρχει μέσα σε ενότητα στοιχείων (elements section) και σημείωση (note). Τα valid XML έγγραφα έχει συγκεκριμένα προοδευτικά χαρακτηριστικά γνωρίσματα, στα οποία δεν μπορούν να έχουν πρόσβαση τα well formed έγγραφα, λόγο της έλλειψης τους σε DTD. Αυτά τα χαρακτηριστικά γνωρίσματα μπορούν να βελτιώσουν σημαντικά την χρησιμότητα του εγγράφου συμπεριλαμβανομένου του: μηχανισμού link, οντότητες (entities) και χαρακτηριστικά (attributes). Τα περισσότερα XML Web sites είναι πιθανώς φτιαγμένα από valid XML έγγραφα, συμμορφωμένα (conforming) με συνήθη DTD, επιτρέποντας στους δημιουργούς τους να δομούν ελευθέρα τα sites τους και να χρησιμοποιούν δημιουργικότερα σετ χαρακτηριστικών από ότι η HTML παραδοσιακά επέτρεπε.
Τα valid XML έγγραφα προσφέρουν πολύ περισσότερα στην επεξεργασία εγγράφου απ’ότι τα αντίστοιχα well formed. Η συγγραφή, επεξεργασία, αποθήκευση, και εμφάνιση του εγγράφου έγιναν ευκολότερες γιατί το έγγραφο υπάρχει σε ένα δομικό περιβάλλον. Οι συγγραφείς πρέπει να δημιουργήσουν έγγραφα με βάση μια προκαθορισμένη δομή επωφελούμενοι από την καθαρό μοντέλο εγγράφου. Όπως και τα well-formed XML, έτσι και τα valid έγγραφα πρέπει να συνοδεύονται από style sheets για να πετύχουν αισθητική εμφάνιση. Η χρήση των CSS, XSL, ή DSSSL style sheets για valid έγγραφα είναι όπως και στα well-formed έγγραφα, εκτός από το ότι τα style sheets μπορεί να φτιαχτούν σύμφωνα με ένα DTD, καθώς εναντιώνεται σε μια σχετικά άγνωστη χρήση του markup.
Μπορείτε
<?
xml version=”1.0” standalone=”no”?>
<!DOCTYPE
MEMO [
<!ELEMENT
MEMO
(TO,FROM,SUBJECT,BODY,SIGN)>
<!ATTLIST
MEMO importance (HIGH | MEDIUM | LOW) “LOW”>
<!ELEMENT
TO
(#PCDATA)>
<!ELEMENT
FROM
(#PCDATA)>
<!ELEMENT
SUBJECT (#PCDATA)>
<!ELEMENT
BODY
(P+)>
<!ELEMENT
P (#PCDATA)>
<!ELEMENT
SIGN (#PCDATA)>
<!ATTLIST
SIGN signatureFile CDATA #IMPLIED
email
CDATA #REQUIRED>
]>
<MEMO
importance=“HIGH”>
<TO>Tutorial
Tarkers</TO>
<FROM>Tutorial
Writer</FROM>
<SUBJECT>Your
impressions</SUBJECT>
<BODY>
<P>Now
that you are almost done the tutorial, you must be getting an idea of what XML
is about. These emerging technologies sometimes take time thou before they
catch on.</P>
<P>Did
you find the tutorial helpful? Which areas did you find confusing? How would
you improve them?</P>
</BODY>
<SIGN
email=“rlander@pdbeam.uwaterloo.ca”>Richard</SIGN>
</MEMO>
Αποθηκεύετε το παραπάνω κείμενο σώζοντάς το με κατάλληξη xml. Το ίδιο κείμενο στον notepad της xml θα έπερνε την εξής μορφή:
Το Document Type Definition εμφανίζεται επιλέγοντας View/Source:
ΠΡΟΣΟΧΗ: Η συγκεκριμένη έκδοση του notepad της XML δεν υποστηρίζει τη δημιουργία XML εγγράφων με DTD αλλά μπορεί να ανοίξει ήδη δημιουργημένα έγγραφα.
Παρακάτω ακολουθούν τα βήματα στα οποία μπορείτε να βασιστείτε για τη σύνταξη valid XML εγγράφων.
Το DTD είναι το θεμέλιο των Valid XML έγγραφων, παρέχοντας τον ορισμό του τύπου του εγγράφου, για τα έγγραφα που θα ακολουθήσουν. Το DTD περιέχει τις απαραίτητες πληροφορίες για την εγγραφή και επεξεργασία του εγγράφου. Χωρίς αυτές τις πληροφορίες, οι αναγνώστες του εγγράφου μπορεί να μην ξέρουν πώς να επεξεργαστούν links, εικόνες ή οντότητες και οι συγγραφείς του εγγράφου θα στερούνται ένα περίγραμμα για την ανάπτυξη.
Προτού σχεδιάσετε ένα DTD θα πρέπει να έχετε σαφή γνώση του τι τύπου έγγραφο θα δημιουργήσετε. Θα πρέπει να διαλέξετε τύπο εγγράφου και να τον ονομάσετε με ονόματα όπως: novel, memo, webpage, letter ή report. Αφού διαλέξετε τον τύπο του εγγράφου σας, μπορείτε να αρχίσετε να «χτίζετε» το δικό σας DTD, επεκτείνοντας το έτσι ώστε να ταιριάζει με τις απαιτήσεις του εγγράφου σας.
Το DTD εμπεριέχει ένα μικρό συντακτικό που μπορεί να μαθευτεί γρήγορα. Αυτό το συντακτικό έχει πολλά στοιχεία αλλά μπορούν να αθροιστούν σε δυο απαραίτητες δομές, οι οποίες είναι το στοιχείο (element) και το χαρακτηριστικό (attribute). Αυτές οι δυο δομές στο έγγραφο χρησιμοποιούνται για να περιγράψουν το περιεχόμενο. Η χρήση τους σε ένα έγγραφο πρέπει να ορίζεται σε ένα DTD για να εξασφαλίζεται ότι τα conforming έγγραφα είναι valid. Το στοιχείο αφετηρίας (element root) είναι το πιο σημαντικό και περιέχει όλα τα αλλά στοιχεια. Αρχίζετε λοιπόν με αυτό, ορίζετε το περιεχόμενο του, μετά ορίζετε τα στοιχεια που είναι στο περιεχόμενο του έως ότου φτάσετε στα στοιχεια επιπέδου κειμένου. Η διαδικασία ορισμού των χαρακτηριστικων (attribute) δεν είναι τόσο κυκλική, απλώς απαιτεί τον ορισμό των χαρακτηριστικών για κάθε στοιχείο (element) που χρησιμοποιεί χαρακτηριστικά. Τα στοιχεια (elements) παίρνουν γενικά την μορφή: <!ELEMENT NAME CONTENT>. Τα χαρακτηριστικά (attributes) συχνά παίρνουν την μορφή: <!ATTLIST ELEMENT-NAME NAME CDATA #IMPLIED>.
Αυτό το DTD περιγράφει τη δομή ενός απλού novel (μυθιστόρημα). Ο τύπος εγγράφου αυτού του DTD είναι novel, όπως μπορείτε να δείτε από το στοιχείο αφετηρίας (root element) που ορίζεται στην πρώτη γραμμή. Το DTD ορίζει για κάθε στοιχείο, το όνομα του και το περιεχόμενο του, και ορίζει και κάθε στοιχείο του περιεχομένου του έως ότου το DTD να είναι πλήρως καθορισμένο. Τα στοιχεια είναι το μόνο επιτρεπτό περιεχόμενο για πολλά από τα στοιχεια αυτού του DTD, και δεν μπορούν να περιέχουν κείμενο απ’ευθειας. Το περιεχόμενο «#PCDATA» σε κάποια από τα στοιχεια σημαίνει ότι επιτρέπεται κείμενο ή χαρακτήρας δεδομένο.
<!ELEMENT
novel (preface,chapter+,biography?,criticalessay*)>
<!ELEMENT
preface (paragraph+)>
<!ELEMENT
chapter (title,paragraph+,section+)>
<!ELEMENT
section (title,paragraph+)>
<!ELEMENT
biography (title,paragraph+)>
<!ELEMENT
criticalessay (title,section+)>
<!ELEMENT
paragraph (#PCDATA| Keyword)*>
<!ELEMENT
title (#PCDATA| keyword)*>
<!ELEMENT
keyword (#PCDATA)>
Ο στόχος αυτού του βήματος είναι η δημιουργία DTD. Η συγγραφή ενός DTD μπορεί να είναι δύσκολη, αλλά ακολουθώντας τις οδηγίες που περιγράφονται εδώ, βλέποντας τα παραδείγματα και κρατώντας το DTD σας απλό, θα μπορέσετε να γράψετε το δικό σας DTD.
Τα DTD είναι φτιαγμένα από δηλώσεις markup, που είναι τύπου στοιχείο (element), λίστα χαρακτηριστικών (attribute list), οντότητας (entity) και notation δηλώσεις. Αυτές οι δηλώσεις καθορίζουν την δομή, παραστατικά, και αποθηκεύουν τις πληροφορίες για ένα τύπο εγγράφου. Σου επιτρέπουν να περιγράψεις ποικίλα κομμάτια του τύπου του εγγράφου σου, ούτος ώστε οι συγγραφείς να μπορούν να παράγουν conforming (προσαρμοσμένα) έγγραφα με ευκολία. Όπως είπαμε στο Βήμα 1 οι δηλώσεις τύπου element και attribute list είναι τα πιο σημαντικές και πιο συχνά χρησιμοποιούμενες δηλώσεις. Αυτό το tutorial θα επικεντρωθεί σε αυτές τις δηλώσεις, μια και είναι πιο χρήσιμες και σχετικά πιο εύκολες για μάθηση.
Οι δηλώσεις για τύπο element ορίζουν τον τύπο των στοιχείων, που έχουν ήδη οριστεί στον markup, σε έγγραφα, σαν element. Κάθε τύπος στοιχείου (element) περιέχει ένα όνομα (name), περιεχόμενο (content) και πιθανώς ένα σετ από χαρακτηριστικά (attribute) και μπορούν να αποφασισθούν πολλές φορές σαν προσαρμοσμένα (conforming) στοιχεια αυτού του τύπο. Το περιεχόμενο του στοιχείου μπορεί να έχει τέσσερις μορφές, από τις οποίες η πιο κοινή είναι mixed- και element-περιεχόμενο. Τα μοντέλα element-περιεχόμενο φτιάχνουν λίστα από γκρουπ στοιχείων και γκρουπ από γκρουπ στοιχείων με συγκεκριμένες σχέσεις μεταξύ τους, για να καθορίσουν το συγκεκριμένο περιεχόμενο των τύπων element. Τα σειριακά γκρουπ περιγράφουν μια απαιτούμενη και τακτική εμφάνιση των μελών τους που χωρίζονται από το σύμβολο «,». Τα γκρουπ επιλογών περιγράφουν μια μόνη εμφανίσει ενός μόνο από τα μέλη τους που χωρίζονται με το σύμβολο «|». Η εμφανίσει κάθε ενός από τα μέλη αυτού του γκρουπ και του ίδιου του γκρουπ μπορεί να αλλάξει από τις παρακάτω ενδείξεις εμφάνισης, οι οποίες ορίζουν την εμφάνιση σαν: «+», απαραίτητη και επαναληπτέα, «*», προαιρετική και επαναληπτέα και «?» προαιρετική. Δηλώσεις τύπου element παίρνουν την παρακάτω μορφή: <!ELEMENT NAME CONTENT>. Το παρακάτω παράδειγμα περιέχει ένα τύπο element, όνομα και σαν περιεχόμενο, ένα σειριακό γκρουπ και φωλιασμένο προαιρετικό-επαναληπτέο γκρουπ επιλογών: <!ELEMENT EXAMPLE (TITLE?, PARA, (PARA | NOTE | CODE) *>. Αυτή η δήλωση τύπου element περιγράφει ένα τύπο element που μπορεί να περιέχει ένα TITLE, πρέπει να περιέχει ένα PARA και που μπορεί να περιέχει κάποιο αριθμό από μη τακτική εμφάνιση από PARA, NOTE και CODE.
Οι δηλώσεις για τύπου element Mixed-περιεχόμενο είναι αρκετά παρόμοιες με τις αντίστοιχες για element-περιεχόμενο αλλά διαφέρει σε κάποια χαρακτηριστικά. Πρέπει να χρησιμοποιούν ένα προαιρετικό-επναληπτέο γκρουπ επιλογών και επίσης πρέπει να περιέχει #PCDATA, κείμενο (text), σαν πρώτο μέλος τους. Τύποι Mixed-περιεχομένου element που δεν περιέχει element-περιεχόμενο αλλά μόνο κείμενο δεν χρησιμοποιεί ένα προαιρετικό-επαναληπτέο γκρουπ επιλογών. Οι δυο παρακάτω δηλώσεις για τύπο element mixed-περιεχομένου που επεξηγούν τις συντακτικές διάφορες μεταξύ element τύπου mixed-περιεχομένου που περιέχει element-περιεχόμενο και αυτών που δεν περιέχουν: <!ELEMENT PARAGRAPH (#PCDATA | Keyword) *> <!ELEMENT Keyword (#PCDATA)>.
Οι δηλώσεις attribute είναι πιο ευμετάβλητες από τις δηλώσεις τύπου element, έχοντας δέκα διαφορετικούς τύπους. Οι πιο κοινοί και απλοί τύποι attribute είναι τα string και enumeration (κατάλογος) attributes. Τα attribute τύπου string, κοινώς ονομαζόμενα CDATA attribute, σας επιτρέπουν να «συλλάβετε» εικονικά αυθόρμητα κείμενα string για να περιγράψουν στοιχείο (element) περιεχόμενο ή συμπεριφορά. Τα enumeration attributes είναι παρόμοια με τα χαρακτηριστικά (attribute) τύπου string αλλά απαιτούν να θέσετε μια λίστα από επιλογές για να μπορεί να κάνει ο συγγραφέας. Και τα δυο αυτά χαρακτηριστικά (attributes) απαιτούν attributes defaults, που μπορεί να είναι: #REQUIRED, απαιτούμενο, #IMPLIED, προαιρετικό, #FIXED “value”, μια καθορισμένη τιμή και , “value”, μια default αλλά παραβιασθεα τιμή. Τα χαρακτηριστικά (attribute) τύπου string παίρνουν τη μορφή: <!ATTLIST ELEMENT-NAME NAME CDATA DEFAULT>. Τα enumeration attributes παίρνουν την μορφή: <!ATTLIST ELEMENT-NAME NAME (choice1 | choice2 | choicen) DEFAULT>. Και οι δυο τύποι χαρακτηριστικών μετατρέπονται στην markup στην παρακάτω μορφή, στην ετικέτα αρχής στοιχείου (element start-tags): , ELEMENT-NAME NAME=”value”>.
Θα πρέπει να «χτίσετε» το δικό σας XML έγγραφο, καθώς διαβάζετε αυτό το tutorial. Κοιτάξτε τη δική σας Valid XML υπόδειξη καθώς διαβάζετε το tutorial, για καθοδήγηση και σαν παράδειγμα. Το δικός σας έγγραφο μπορεί να είναι κάπως διαφορετικό από αυτό το παράδειγμα αλλά θα πρέπει να έχει «χτιστεί» με τον ίδιο τρόπο. Σε αυτό το σημείο της δημιουργίας εγγράφου XML, δεν έχετε καθόλου έγγραφο, αλλά το DTD με το οποίο θα συνδέεται το έγγραφο. Προσέξτε πως αυτό το παράδειγμα χρησιμοποιεί δηλώσεις τύπου element για να συλλάβει το περιεχόμενο του εγγράφου και δηλώσεις τύπου attributes για να περιγράψει συγκεκριμένα τμήματα του.
<!ELEMENT
MEMO (TO, FROM, SUBJECT,BODY, SIGN) >
<!ATTLIST
MEMO importance
(HIGH | MEDIUM | LOW) “LOW” >
<!ELEMENT
TO (#PCDATA)>
<!ELEMENT
FROM (#PCDATA)>
<!ELEMENT
SUBJECT (#PCDATA)>
<!ELEMENT
BODY (P+)>
<!ELEMENT
P (#PCDATA)>
<!ELEMENT
SIGN (#PCDATA)>
<!ATTLIST
SIGN siqnatureFile CDATA
#IMPLIED
email CDATA #REQUIRED>
Οι παρακάτω χειριστές ακολουθίας και επιλογής, και ενδείξεις εμφάνισης τροποποιεί την φύση του τύπου element.
Όρος Ερμηνεία
, Χειριστής ακολουθίας που χωρίζει μέλη τις λίστας ακολουθίας, που απαιτεί ακολουθιακή χρήση όλων των μελών.
| Χειριστής επιλογής που χωρίζει μέλη της λίστας επιλογής, που απαιτεί την χρήση ενός και μόνο από τα μέλη. Αυτό το non-symbol δείχνει εμφάνιση.
+ Αυτό το σύμβολο δείχνει μια απαραίτητη και επαναληπτέα εμφάνιση.
* Αυτό το σύμβολο δείχνει προαιρετική και επαναληπτέα εμφάνιση.
? Αυτό το σύμβολο δείχνει προαιρετική εμφάνιση.
Ο στόχος αυτού του βήματος είναι να δημιουργήσετε μια XML δήλωση, που δηλώνει την φύση του εγγράφου XML στον αναγνώστη του εγγράφου. Χωρίς αυτή τη δήλωση, ένας αναγνώστη εγγράφου μπορεί να αναγνωρίσει λάθος ένα XML έγγραφο σαν SGML, HTML ή RTF, προκαλώντας προβλήματα ερμηνείας.
Κάθε XML έγγραφο πρέπει να χρησιμοποιεί μια XML δήλωση, για να εξηγήσει την φύση του σε αναγνώστες XML εγγράφων. Editors, browsers και επεξεργαστές εγγράφων χρησιμοποιούν την δήλωση για να καθορίσουν πως θα πρέπει ένα έγγραφο να επεξεργαστεί. Η δήλωση γίνεται όλο και περισσότερο απαραίτητη με μεγάλα και πολύπλοκα έγγραφα αλλά πρέπει επίσης να χρησιμοποιείται και σε μικρότερα και δοκιμαστικά έγγραφα. Η δήλωση XML περιλαμβάνει πληροφορίες πάνω στην markup language (γλώσσα), την έκδοση της markup γλώσσας, την παρουσία εξωτερικών markup δηλώσεων και κωδικοποίηση χαρακτήρων.
Αυτές οι XML δηλώσεις χρησιμοποιούνται γενικά για ποικίλους τύπους XML συγγραφής. Οι πρώτες δυο δηλώσεις μπορούν να χρησιμοποιηθούν για να περιγράψουν well-formed και valid XML έγγραφα, αντίστοιχα. Η τρίτη δήλωση μπορεί να θεωρηθεί default XML δήλωση, δηλώνοντας ότι είναι έγγραφο XML έκδοσης 1.0, και ότι δεν μπορεί να σταθεί από μόνο του (standalone) χωρίς εξωτερικές markup δηλώσεις και ότι είναι κωδικοποιημένο σε UTF-8, μια 8-bit Unicode κωδικοποίησης χαρακτήρων.
<?xml
version=”1.0” standalone=”yes”?>
<?xml
version=”1.0” standalone=”no”?>
<?xml
version=”1.0” standalone=”no” encoding=”UTF-8”?>
Μπορεί να έχετε μπερδευτεί και να αναρωτιέστε που πήγε το DTD. Θεωρείστε ότι είναι σωσμένο σε άλλο αρχείο και αναμένει να χρησιμοποιηθεί. Είναι πολύ σημαντικό το να χτίσετε το DTD πριν γράψετε το έγγραφο αλλά το έγγραφο πρέπει να υποστεί προκαταρκτική ανάπτυξη πριν μπορέσει να χρησιμοποιήσει το DTD. Το έγγραφο σας πρέπει να αρχίζει με μια XML δήλωση και πρέπει να είναι παρόμοιο με αυτό το έγγραφο σε αυτό προ πρωταρχικό στάδιο της ανάπτυξης του.
<?xml
version=”1.0” standalone=”no”?>
Όρος Ερμηνεία
<?xml Αρχίζει την δήλωση XML, ένα είδος οδηγίας για την επεξεργασία.
version Η δήλωση version περιγράφει την έκδοση της XML που χρησιμοποιείται, που πρέπει να είναι ίση με “1.0”, καθώς η XML 1.0 είναι η τωρινή και μόνη έκδοση της XML.
standalone Η Standalone δήλωση εγγράφου επιτρέπει στον συγγραφέα του εγγράφου να διευκρινίζει αν υπάρχουν εξωτερικές markup δηλώσεις. Αυτό το χαρακτηριστικό μπορεί να είναι ίσο με yes ή no και είναι συνήθως το τελευταίο στα valid έγγραφα.
encoding H encoding δήλωση επιτρέπει στον συγγραφέα να καθορίσει τον χαρακτήρα κωδικοποίησης που θα χρησιμοποιηθεί. Αυτή η δήλωση πρέπει να χρησιμοποιείται μόνο από συγγραφείς που χρησιμοποιούν χαρακτήρα κωδικοποίησης εκτός του US-ASCII, τον πιο κοινό, ή τον UTF-8.
?> Κλείνει την XML δήλωση.
Σκοπός αυτού του βήματος είναι να περιλάβετε μια δήλωση τύπου εγγράφου στο έγγραφο σας, το οποίο θα οδηγεί (link) ή θα περιλαμβάνει το δικό σας DTD. Η δήλωση τύπου εγγράφου (DTD) ονομάζει τον τύπο του εγγράφου που χρησιμοποιείται και οδηγεί (link) ή περιλαμβάνει τον ορισμό του, το DTD.
Η δήλωση τύπου εγγράφου, που τοποθετείται μετά την δήλωση XML, είναι ένας μηχανισμός για την ονομασία του τύπου του εγγράφου με τον οποίο συμμορφώνεται το έγγραφο και δείχνει ή περιλαμβάνει τον ορισμό του. Τα Valid XML έγγραφα πρέπει να δηλώνουν τον τύπο εγγράφου με τον οποίο συμμορφώνονται και παρέχουν τον πλήρη ορισμό του έτσι ώστε οι editors, οι browsers και οι μετατροπείς (converters) να μπορούν να διαβάσουν το DTD του για να το κατανοήσουν. Τα well-formed έγγραφα μπορούν επίσης να περιλάβουν δήλωση τύπου εγγράφου και να περιλάβουν markup δηλώσεις στα εξωτερικά τους subset αλλά δεν είναι απαραίτητο να πράξουν έτσι. Η δήλωση τύπου εγγράφου ονομάζει του τύπο εγγράφου κάνοντας αναφορά στο στοιχειο αφετηρίας (root element) του εγγράφου. Μπορεί να κάνει αναφορά σε ένα εξωτερικό DTD, που καλείται external DTD subset, να περιλαμβάνει το DTD εσωτερικά στο internal DTD subset, ή και τα δυο. Η δήλωση τύπου εγγράφου παίρνει γενικά την μορφή: <!DOCTYPE NAME SYSTEM “file”[ ]>.
Η χρήση της δήλωσης τύπου εγγράφου είναι πολύτιμη, εξαρτάται από το DTD υποσύνολο (subset) που χρησιμοποιείται για να περιέχει το DTD. Το DTD μπορεί να «στεγαστεί» αποκλειστικά είτε σε εξωτερικό (external), είτε σε εσωτερικό (internal) υποσύνολο, ή και στα δυο. Σε κάθε μια από αυτές τις επιλογές μπορεί να χρησιμοποιηθεί ελαφρώς διαφορετική σύνταξη. Η πιο απλή δήλωση, η οποία επιτρέπει μόνο εξωτερικό (external) υποσύνολο (subset) του DTD που ακολουθεί: <!DOCTYPE NAME SYSTEM “file”>. Η ακόλουθη δήλωση επιτρέπει την χρήση ενός από τους δύο τύπους υποσυνόλων ή και τους δυο και είναι και ποιο γνωστή: <!DOCTYPE NAME SYSTEM “FILE” [ ]>. Το [ ] στεγάζει το εσωτερικό υποσύνολο. Η τελευταία δήλωση επιτρέπει μόνο την χρήση εσωτερικού υποσύνολο: <!DOCTYPE NAME [ ]>.
Αν το στοιχείο αφετηρίας (root element) είναι ένα συγκεκριμένο DTD το poem τότε η δήλωση τύπου εγγράφου θα διαβάσει <!DOCTYPE poem [ ]>. Ο ορισμός του poem τύπου εγγράφου θα πρέπει να περιλαμβάνεται σε ένα εσωτερικό DTD υποσύνολο, μαρκαρισμένο από τους [ και το ] δείκτες. Αυτός ο ορισμός θα μπορούσε επίσης να σωθεί σε ένα εξωτερικό αρχείο και να συνδεθεί (link) με την δήλωση του τύπου εγγράφου στην παρακάτω μορφή: <!DOCTYPE poem SYSTEM “poem.dtd”>.
Θα πρέπει να προσθέσετε μια δήλωση τύπου εγγράφου στο δικό σας XML έγγραφο, που θα ονομάζει το τύπο του εγγράφου σας, θα δείχνει ίσως στο εξωτερικό υποσύνολο ή θα περιλαμβάνει ένα εσωτερικό υποσύνολο, το οποίο θα είναι μαρκαρισμένο από τους δείκτες [ και ]. Αυτό το παράδειγμα ονόμασε τον τύπο του εγγράφου σαν MEMO, δεν δείχνει σε εξωτερικό υποσύνολο, αλλά περιλαμβάνει markup δηλώσεις σε ένα εσωτερικό υποσύνολο. Το DTD θα μπορούσε το ίδιο απλά να αποθηκευτεί σαν ένα εξωτερικό αρχείο και να χρησιμοποιήσει την παρακάτω δήλωση τύπου εγγράφου: <!DOCTYPE MEMO SYSTEM “memo.dtd”>.
<?xml
version=”1.0” standalone=”no”?>
<!DOCTYPE
MEMO [
<!ELEMENT
MEMO
(TO,FROM,SUBJECT,BODY,SIGN)>
<!ATTLIST
MEMO importance (HIGH | MEDIUM | LOW)
“LOW”>
<!ELEMENT
TO
(#PCDATA)>
<!ELEMENT
FROM
(#PCDATA)>
<!ELEMENT
SUBJECT (#PCDATA)>
<!ELEMENT
BODY
(P+)>
<!ELEMENT
P (#PCDATA)>
<!ELEMENT
SIGN (#PCDATA)>
<!ATTLIST
SIGN signatureFile CDATA
#IMPLIED
email
CDATA #REQUIRED>
]>
Όρος Ερμηνεία
<!DOCTYPE Αρχίζει την δήλωση τύπου του εγγράφου.
NAME Ονομάζει τον τύπο του εγγράφου όπως σαφώς ορίστηκε, και πρέπει να ακολουθεί τους κανόνες XML NAME.
SYSTEM Δείχνει ότι ένας system identifier, που ακολουθεί πρέπει να διαβαστεί και να αναλυθεί.
“report.dtd” Αναφορά σε system identifier, που πρέπει να αναλυθεί για να εντοπισθεί το DTD.
[ Αρχίζει ένα εσωτερικό υποσύνολο.
Το εσωτερικό DTD υποσύνολο, που μπορεί να περιέχει αριθμό markup δηλώσεων.
] Τελειώνει το εσωτερικό υποσύνολο.
> Κλείνει τη δήλωση τύπου εγγράφου.
Ο σκοπός αυτού το βήματος είναι να γράψετε ένα valid XML έγγραφο, σιγουρεύοντας ότι είναι συμμορφωμένο με το DTD σας. Αφού κοπιάσαμε με το DTD, το γράψιμο του εγγράφου είναι εύκολο. Η Valid XML είναι πραγματικά ευκολότερη στο γράψιμο από ότι η well formed XML γιατί απλά ακολουθείς τη δομή του DTD, ο οποίο απαιτεί πολύ λιγoτερες επιλογές.
Η συγγραφή Valid XML εγγράφου είναι πολύ διαφορετική από ότι του well-formed XML. Πρέπει να ακολουθείτε το DTD που εσείς γράψατε, σιγουρεύοντας ότι δεν θα σπάσετε κανένα από τους κανόνες που εσείς γράψατε. Αν το έγγραφο σας γίνει μη-συμμορφωμένο (non-conformant), καλά θα κάνετε να το φτιάξετε, γιατί αλλιώς πιθανώς να μην εμφανιστεί ή επεξεργαστεί σωστά όταν το χρησιμοποιήσετε. Το έγγραφο σας πρέπει να περιέχει δηλώσεις XML και τύπου εγγράφου. Βαλτέ ετικέτες αρχής και τέλους για το στοιχείο αφετηρίας (root element) σας. Ακολουθήστε το DTD επακριβώς, δίνοντας προσοχή στους κανόνες περιεχομένου για κάθε στοιχείο, σιγουρεύοντας ότι συμμορφώνεστε εκεί που απαιτείται και να επιλέγετε εκεί που επιτρέπεται.
Τα λάθη είναι ένα μεγάλο πρόβλημα για αυτούς που αναπτύσσουν έγγραφα. Αν προσέξετε το γράψιμο σας και σιγουρευτείτε ότι ακολουθείτε το DTD, θα αποφύγετε τα λάθη. Βεβαιωθείτε ότι τα στοιχεια σας είναι φωλιασμένα σωστά, καθώς overlapping στοιχεια προκαλούν λάθη. Αν βρείτε ότι το DTD σας είναι πολύ αυστηρό για το έγγραφο που θέλετε να γράψετε τότε τροποποιήστε το DTD σας. Το DTD είναι δικό σας και μπορεί να τροποποιηθεί αν χρειαστεί. Κρατείστε την συνολική δομή του εγγράφου στο μυαλό σας, σιγουρεύοντας ότι η απόδοση του σε XML είναι σωστή και βγάζει νόημα.
<?
xml version=”1.0” standalone=”no”?>
<!DOCTYPE
MEMO [
<!ELEMENT
MEMO
(TO,FROM,SUBJECT,BODY,SIGN)>
<!ATTLIST
MEMO importance (HIGH | MEDIUM | LOW)
“LOW”>
<!ELEMENT
TO
(#PCDATA)>
<!ELEMENT
FROM
(#PCDATA)>
<!ELEMENT
SUBJECT (#PCDATA)>
<!ELEMENT
BODY
(P+)>
<!ELEMENT
P (#PCDATA)>
<!ELEMENT
SIGN (#PCDATA)>
<!ATTLIST
SIGN signatureFile CDATA #IMPLIED
email
CDATA #REQUIRED>
]>
<MEMO
importance=“HIGH”>
<TO>Tutorial
Tarkers</TO>
<FROM>Tutorial
Writer</FROM>
<SUBJECT>Your
impressions</SUBJECT>
<BODY>
<P>Now
that you are almost done the tutorial, you must be getting an idea of what XML
is about. These emerging technologies sometimes take time thou before they
catch on.</P>
<P>Did
you find the tutorial helpful? Which areas did you find confusing? How would
you improve them?</P>
</BODY>
<SIGN
email=“rlander@pdbeam.uwaterloo.ca”>Richard</SIGN>
</MEMO>
Ο σκοπός του βήματος αυτού είναι να βεβαιωθείτε ότι το έγγραφο σας είναι well-formed και valid. Αν το έγγραφο σας δεν είναι συμμορφωμένο με τους κανόνες της XML και του DTD σας, μπορεί να μην διαβάζεται σωστά από έναν XML αναγνώστη. Τα λάθη μπορεί να καταστρέψουν την δουλεία που έχετε κάνει στο έγγραφο και μπορεί να απαιτούν πολύ δουλεία για να θεραπεύσουν το πρόβλημα ειδικά αν είναι error-dense. Τα περισσότερα valid XML έγγραφα είναι φτιαγμένα σε validating XML editors, οι οποίοι είναι σχεδιασμένοι για να αποφεύγουν λάθη και συχνά να μην τα επιτρέπουν.
Αφού επενδύσετε το χρόνο σας για να δημιουργήσετε ένα XML έγγραφο, θα περιμένετε να συμπεριφέρεται σωστά. Αν το έγγραφο σας δεν είναι πλήρως well-formed, μπορεί να μην φέρεται όπως θα θέλαμε. Βεβαιωθείτε ότι όλα τα στοιχεια (element) έχουν ετικέτες αρχής και τέλους, ειδικά το στοιχείο αφετηρίας (root element) σας. Όλες οι ετικέτες τέλους και αρχής των στοιχείων πρέπει να φωλιάζουν σωστά σε υψηλότερα στοιχεια, που σημαίνει ότι τα στοιχεια δεν μπορούν να παρακάμπτουν, όπως με τα car και engine elements στο παράδειγμα παρακάτω. Επίσης τσεκάρετε αν όλα τα attributes σας χρησιμοποιούν μόνα ή δίπλα εισαγωγικά και ότι κάθε τιμή χαρακτηριστικά (attribute) περιέχεται μέσα σε ένα μόνο τύπο εισαγωγικών.
Ένας καλύτερος, και πιο ακριβής τρόπος έλεγχου του πόσο well-formed και valid είναι το valid XML έγγραφο σας είναι η χρήση ενός αναλυτή (parser), ο οποίος ελέγχει το έγγραφο σας για λάθη. Σιγουρευτείτε ότι χρησιμοποιείτε validating XML parser αν ελέγχετε valid XML έγγραφα. Οι parsers μπορεί να γίνουν πολύ εξυπηρετικοί όταν δεν μπορείτε να βρείτε το λόγο γιατί το έγγραφο δεν διαβάζεται σωστά. Είναι επίσης πολύ καλό εργαλείο για τον έλεγχο των εγγράφων σας όπως τα δημιουργείτε και πριν τα χρησιμοποιήσετε. Ο James Clark παρέχει ένα εύχρηστο parser, που καλείτε NSGMLS, που περιλαμβάνεται στο SP και Jake packages του. μπορείτε να χρησιμοποιήσετε την ακόλουθη NSGMLS εντολή για να ελέγξετε το κατά πόσο το έγγραφο σας είναι well-formed και valid: NSGMLS –s xml.dcl yourfile.xml. Πολλοί parser υπάρχουν για αυτό το σκοπό.
Αυτά τα παραδείγματα parsing δείχνουν κοινά λάθη και σωστή χρήση elements. Τα πρώτα δυο παραδείγματα είναι well-formed XML, ενώ τα ακόλουθα είναι από αυτά που θα παράγουν parsing λάθη, καθώς δεν είναι well-formed. Μοντελοποιήστε τα elements σας σύμφωνα με τα πρώτα δυο παραδείγματα, ακολουθώντας τους κανόνες well-formed. Βεβαιωθείτε ότι το markup σας συμφωνεί με το DTD σας, καθώς το κατά πόσο το έγγραφο σας είναι valid είναι σχεδόν το ίδιο σημαντικό με τον αν είναι well-formed στα valid XML έγγραφα.
<PRICE>$57.80</PRICE>
<PET><CAT
type=“Corish Rex”>Cat nestes properly within
PET.</CAT><PET>
<WEATHER>foggy
<LEVEL>intermediate<LEVEL>
<PASSWORD>planetB612</PASSWD>
<DISTANCE
TYPE=KM120</DISTANCE>
<CAR><engine>engine
does not net properly within CAR</CAR></engine>
 |
 |
 |