1 / 34

Document Type Definitions (DTD) Basic Valid XML

Document Type Definitions (DTD) Basic Valid XML. Dr. Awad Khalil Computer Science Department AUC. Content. Why DTDs. How to write simple DTDs, and the benefits of using them. How to use DTDs.

harlan
Download Presentation

Document Type Definitions (DTD) Basic Valid XML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Document Type Definitions(DTD)Basic Valid XML Dr. Awad Khalil Computer Science Department AUC DTD, by Dr. Khalil

  2. Content • Why DTDs. • How to write simple DTDs, and the benefits of using them. • How to use DTDs. DTD, by Dr. Khalil

  3. Well-formed XML data is guaranteed to use proper XML syntax, and have the properly nested (hierarchical) tree structure that’s common to all XML data. This may be sufficient information for relatively static internal applications, particularly if the XML data is computer-generated and computer-consumed. The XML structural information and the logic to do this are usually hard-coded separately within the sending and receiving applications, from a common specification. This can be an efficient, high-performance approach to handling XML data in certain limited circumstances. For example, an internal cooperate application might use well-formed XML as a data transfer mechanism between two different database management systems (DBMSs). Using XML as a transfer syntax would decouple the two DBMSs from each other, so that the transfer could just as easily be directed to a third DBMS without needing to create yet another point-to-point transfer program. However, when there’s no formal description of the XML data, it’s difficult to describe or modify the structure of that data, since it’s structure and content constraints are buried within the application code. Any changes to the data structure must be made simultaneously in both the sending and receiving applications, and in the separate technical documentation as well. Why Do We Need DTDs? DTD, by Dr. Khalil

  4. In addition to ensuring that XML data is simply well-formed, most XML applications will also need to: Describe document structure, preferably in a rigorous and formal manner. Communicate document structure to other applications and people. Check that the required elements are present – and prompt the author for their inclusion if they aren’t. Check that no disallowed elements are included – and prevent the author from using them. Enforce element content, tree structure, and element attribute values. Provide default values for unspecified attribute values. Use standard document formats and data structures. XML Application Requirements DTD, by Dr. Khalil

  5. One Solution – The Document Type Definitions • A solution to these requirements is based on separating the XML data description from individual applications which allows all cooperating applications to share a single description of the data. This description of data is known as the XML vocabulary. • A group of XML documents that share a common XML vocabulary is known as a document type, and each individual document that conforms to a document type is a document instance. • The XML 1.0 specification provides a standardized means of describing XML document types: the Document Type Definitions (DTD). • DTDs are XML documents which can either be incorporated within the XML document containing the data, or exist as a separate document. They define the rules that set out how a document should be structured, what elements should be included, what kind of data may be included and what default values to use. DTD, by Dr. Khalil

  6. Well-formed XML documents are those that comply with the basic syntax and structural rules of the XML 1.0 specifications. Valid XML documents are well-formed documents that also comply with syntax, structural, and other rules as defined in a DTD. Multiple documents and applications can share DTDs. Having a central description of the XML data and a standardized validation method lets us move both data description and validation code out of numerous individual applications. The data description code becomes the DTD, and the validation code is already present (and optimized) in the validating XML parser. This greatly simplifies our application code, and thus improves both performance and reliability. Valid XML is also preferable to simple well-formed XML for most document-oriented data.Being able to define such rules will become more important as we exchange , process, and display XML in a wider environment, such as in a B2B or e-commerce scenario. Using DTDs will allow us not only to determine that XML documents follow the syntax rules of the XML specification, but also that they follow our own rules regarding content and structure. Valid XML DTD, by Dr. Khalil

  7. To ensure that an XML document is not just well-formed, but valid, as well: fxp http://www.informatik.uni-tier.de/~neumann/fxp Java Project X Tr2 http://developer.java.sun.com/developer/products/xml MSXML “preview” http://msdn.microsoft.com/downloads/webtechnology/xml/msxml.asp rxp http://www.cogsci.ed.ac.uk/~richard/rxp.html STG Validator http://www.stg.brown.edu/service/xmlvalid XJParser http://xdev.datachannel.com/downloads/xjparser XML4C / XML4J http://www.alphaworks.ibm.com/formula/xml XML for Java v2 http://technet.oracle.com/tech/xml/parser_java2 Xerces-C++ http://xml.apache.org/xerces-c/index.html Xerces-J http://xml.apache.org/xerces-j/index.html Validating Parsers DTD, by Dr. Khalil

  8. Shared DTDs are a very powerful aspect of XML Shared DTDs are the basis for many XML vocabularies. Using a shared data description greatly simplifies the process of creating and maintaining an XML vocabulary. It can also make any application code simpler, and thus more reliable and easier to maintain. With a shared DTD, there’s only one place where we need to make modifications to the vocabulary’s data description, instead of three (the specification, sending application, and receiving application). Having standardized XML vocabularies for common things (such as bibliographic information, for example) allows developers to reuse existing DTDs, saving the cost of developing custom DTDs. Custom DTDs isolate their users and applications from others that might otherwise be able to share commonly formatted documents and data. Shared DTDs are the foundation of XML data interchange and reuse. Sharing DTDs DTD, by Dr. Khalil

  9. The BookCatalog DTD is an example of a shared XML vocabulary that can be used by a publisher to communicate with its distributors, retailers, and other interested parties. An XML-aware browser will allow users to learn about future publications, read reviews of existing books, or even order books directly from the catalog. Why XML? A single common standard syntax Easily shared vocabularies Standard methods and tools for transforming data Utilization of existing Internet protocols such as HTTP Why DTDs? Provide a formal and complete definition of an XML vocabulary Are sharable descriptions of the structure of an XML document Are a way to validate specific instances of XML documents and constrain their content Are restricted to one DTD per document instance Other Alternatives to DTDs XML-data XML-Data-Reduced XML Schemas – are well on their way to becoming a formal W3C recommendation An Example – A Book Catalog DTD, by Dr. Khalil

  10. Before we can create a DTD, we first need to develop a data model that describes the BookCatalog vocabulary and its grammer: Catalog – A document header describing the rest of the document Publisher – Vendor of Books, employer of Authors Author – Creator of Books, employee of Publisher Book – Creation of Author and Publisher The Basic BookCatalog Data Model DTD, by Dr. Khalil

  11. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <BookCatalog> <Catalog> <CatalogTitle>The Wrox BookCatalog ('Basic' version)</CatalogTitle> <CatalogDate>2000-05-23</CatalogDate> </Catalog> <Publisher> <CorpName>Wrox Press Ltd.</CorpName> <Website>www.wrox.com</Website> <Address> <Street>Arden House</Street> <Street>1102 Warwick Road</Street> <Street>Acocks Green</Street> <City>Birmingham</City> <Region>England</Region> <PostalCode>B27 6BH</PostalCode> <Country>UK</Country> </Address> </Publisher> <Publisher> <CorpName>Wrox Press Inc.</CorpName> <Website>www.wrox.com</Website> <Address> <Street>29 S LaSalle St, Suite 520</Street> <City>Chicago</City> <Region>IL</Region> <Country>USA</Country> <PostalCode>60603</PostalCode> </Address> </Publisher> <Book> <ISBN>1-861003-11-0</ISBN> <Title>Professional XML</Title> <Author>Didier Martin</Author> <Author>Mark Birbeck</Author> <Author>Michael Kay</Author> <Author>Brian Loesgen</Author> <Author>Jon Pinnock</Author> <Author>Steven Livingstone</Author> <Author>Peter Stark</Author> <Author>Kevin Williams</Author> <Author>Richard Anderson</Author> <Author>Stephen Mohr</Author> <Author>David Baliles</Author> <Author>Bruce Peat</Author> <Author>Nikola Ozu</Author> <Editor>Jon Duckett</Editor> <Editor>Peter Jones</Editor> <Editor>Karli Watson</Editor> <Abstract>The complete practical encyclopedia for XML today.</Abstract> <Pages>1169</Pages> <Price>$49.99</Price> <Subjects> <Subject1>Internet</Subject1> <Subject2>Internet Programming</Subject2> <Subject3>XML</Subject3> </Subjects> </Book> </BookCatalog> Basic BookCatalog Document (BookCatalogBasic.xml) DTD, by Dr. Khalil

  12. Only one DTD can be associated with a given XML document. The DTD may be divided into two parts: The internal subset – which is the part of DTD included within the document The external subset – which is the set of declarations that are located in a separate document (might be a database record or a .dtd file). There’s no requirement that a DTD uses a particular subset. A DTD might be contained entirely within the document (an internal subset), with no external subset, or a document may simply refer to an external subset and contain no DTD declarations of its own. So, there are three possible forms of DTD: An internal subset DTD An external subset DTD A combined DTD, using both the internal and external subsets DTD declarations in the internal subset have priority over those in the external subset. Internal versus External DTDs DTD, by Dr. Khalil

  13. Each XML document can be associated with one, and only one, DTD using a single DOCTYPE declaration, via the following basic structure: <!DOCTYPE document _element source location1 location2 [ internal subset of DTD ]> Document_element – is the name of the document element. This name is required and connects the DTD to the entire element tree: <?xml version=“1.0” encoding=“UTF-8” standalone=“yes”> <!DOCTYPE BookCatalog … > … <BookCatalog> … </BookCatalog> DTDs are always associated with the document element. source – used to associate an external subset with a document, (SYSTEM or PUBLIC). In the following example, the parser will attempt to retrieve the DTD from the specified URL AT Wrox’s website: <!DOCTYPE BookCatalog SYSTEM “http://www.wrox.com/DTDs/BookCatalog.dtd> A document residing on the same web server as the DTD could also access the DTD directly: <!DOCTYPE BookCatalog SYSTEM “file://DTDs/BookCatalog.dtd” > Using the PUBLIC keyword allows a non-specific reference to the DTD via a URI: <!DOCTYPE BookCatalog PUBLIC “PublishingConsorium/BookCatalog” > <!DOCTYPE BookCatalog PUBLIC “PublishingConsorium/BookCatalog” “http://www.wrox.com/DTDs/BookCatalog.dtd> Associating a DTD with an XML document (DOCTYPE) DTD, by Dr. Khalil

  14. Let’s create a simple DTD and demonstrate linking it to two different document instances. Let’s stipulate that this DTD requires a conforming document to have exactly three empty elements, named X, Y, Z, with the elements appearing in XYZ order. We create the following BookCatalogTrivial.dtd: <!ELEMENT BookCatalog (X, Y, Z) > <!ELEMENT X EMPTY > <!ELEMENT Y EMPTY > <!ELEMENT Z EMPTY > Now, we create two example documents: BookCatalogTrivial.xml: <?xml version=“1.0” ?> <!DOCTYPE BookCatalog SYSTEM “BookCatalogTrivial.dtd” > <BookCatalog> <X /> <Y /> <Z /> </BokkCatalog> BookCatalogAbsentDTD.xml: <?xml version=“1.0” ?> <!DOCTYPE BookCatalog SYSTEM “MissingDTD.dtd” > <BookCatalog> <X /> <Y /> <Z /> </BokkCatalog> An Example – DOCTYPE Declaration (Linking a DTD to a Document) DTD, by Dr. Khalil

  15. Basic DTD Markup • DTD declarations are delimited with the XML tag delimiters <“<“ and “>”). • All DTD declarations are indicated by the use of the exclamation mark (“!”) followed by a keyword, and its specific parameters: <!Keyword parameter1 parameter2 .. parameterN > • There are four basic keywords used in DTD declarations: • ELEMENT – Declares an XML element type name ant its permissible sub-elements (“children”). • ATTLIST – Declares XML element attribute names, plus permissible and/or default attribute values. • ENTITY – Declares special character references, text macros (much like a C/C++ #define statement), and other repetitive content from external sources (like a C/C++ #include). • NOTATION – Declares external non-XML content (for example, binary image data) and the external application that handles that content. DTD, by Dr. Khalil

  16. Elements are described using the element type declaration, which can have one of two different forms: <!ELEMENT name category > <!ELEMENT name (content_model) > The category(content category) and content_model (content model) parameters describe what kind of content (if any) may appear within elements of the given name. There are five categories of element content: ANY – Elements type may contain any well-formed XML data. EMPTY – Element type may not contain any text or child elements – only element attributes are permitted. element – Element type contains only child elements – no additional text is permitted within the element type. mixed – Element type may contain text and/or child elements. PCDATA – Element type may contain text (character data) only. Examples: <!ELEMENT AnythingGoesInHere Any> ------------------------------------------------------ <!ELEMENT BR EMPTY> <!ELEMENT EOF EMPTY> <!ELEMENT PrserConfig EMPTY> <!ELEMENT BrowserConfig EMPTY> -------------------- <ParserConfig valditate=“yes” externalentity=“no” keepcomments=“no” /> <BrowserConfig showags=“yes” showcomments=“no” showPIs=“no” /> Element Type (ELEMENT) Declarations DTD, by Dr. Khalil

  17. Content models are used to describe the structure and content of a given element type. This content may be: Character data (PCDATA) One or more child element types (element-only content) A combination of the two (mixed content) <!ELEMENT name ( ..content_model.. ) > The key difference between element content and mixed content is the use of the #PCDATA keyword. If present, the content model is either mixed or PCDATA. The absence of this keyword indicates element-only content. Examples: <name> Character data can include entity references (e.g. &amp; or &lt;). </name> <!ELEMENT name (#PCDATA) > ------------------------------------------------------- <name> <a_child_element>Some element content ..</a_child_element> <another_child_element>...some other childish content..</another_child_element> <a_third_element>...yet another child’s content..</a_third_element> </name> <!ELEMENT name (a_child_element, another_child_element, a_third_element) > Child elements may be constrained to appear in a specific sequence (sequence list). ------------------------------------------------------- <!ELEMENT name (#PCDATA, a_child_element, another_child_element, a_third_element) > In a mixed content model, child elements are constrained to character data plus a simple list of valid child element types, without any sequence or choice specifications. Content Models DTD, by Dr. Khalil

  18. Consider the following DTD: <!ELEMENT PersonName (Title, FirstName, MiddleName, LastName, Suffix) > <!ELEMENT Title (#PCDATA) > <!ELEMENT FirstName (#PCDATA) > <!ELEMENT MiddleName (#PCDATA) > <!ELEMENT LastName (#PCDATA) > <!ELEMENT Suffix (#PCDATA) > A document instance that conforms to this declaration: <PersonName> <Title>Mr</Title> <FirstName>John</FirstName> <MiddleName>Q</MiddleName> <LastName>Public</LastName> <Suffix></Suffix> </PersonName> We could use choice of specific empty elements to replace the two text-containing elements: <!ELEMENT PersonName ( (Mr | Ms | Dr | Rev), FirstName, MiddleName, LastName, (Jr | Sr | III) ) > <!ELEMENT Mr (#PCDATA) > <!ELEMENT Ms (#PCDATA) > <!ELEMENT Dr (#PCDATA) > <!ELEMENT Rev (#PCDATA) > <!ELEMENT FirstName (#PCDATA) > <!ELEMENT MiddleName (#PCDATA) > <!ELEMENT LastName (#PCDATA) > <!ELEMENT Jr EMPTY > <!ELEMENT Sr EMPTY > <!ELEMENT III EMPTY > The conforming document instance would now becomeext-containing elements: <PersonName> <Mr/> <FirstName>John</FirstName> <MiddleName>Q</MiddleName> <LastName>Public</LastName> <Jr/> </PersonName> Content Models (Cont’d) DTD, by Dr. Khalil

  19. Cardinality operators – define how many child elements may appear in a content model: (none) – The absence of a cardinality operator character indicates that one, and only one, instance of the child element is allowed (required). ? – Zero or one child element (optional singular element). * - Zero or more child elements (optional elements). + - One or more child elements (required elements) Consider the following DTDs: <!ELEMENT PersonName ( (Mr | Ms | Dr | Rev) ?, FirstName, MiddleName*, LastName, (Jr | Sr | III) ?) > <!ELEMENT PersonName ( SingleName | ( (Mr | Ms | Dr | Rev) ?, FirstName, MiddleName*, LastName, (Jr | Sr | III) ?) ) > Here are some conforming instances: <PersonName> <Mr /> <FirstName>John</FirstName> <MiddleName>Q</MiddleName> <MiddleName>P</MiddleName> <LastName>Public</LastName> <Jr /> </PersonName> <PersonName> <FirstName>Jane</FirstName> <LastName>Doe</LastName> </PersonName> <PersonName> <SingleName>Madonna</SingleName> </PersonName> Content Models (Cont’d) DTD, by Dr. Khalil

  20. Consider the following DTDs: <!ELEMENT PersonName ( SingleName | ( (Mr | Ms | Dr | Rev) ?, FirstName, MiddleName*, LastName, (Jr | Sr | III) ?) ) > Here are some non-conforming (“not valid”) instances: <PersonName> <LastName>Smith</LastName> <FirstName>Bob</FirstName> </PersonName> <PersonName> <Miss /> <FirstName>Jane</FirstName> <LastName>Doe</LastName> </PersonName> <PersonName> <SingleName>Madonna</SingleName> <SingleName>Cicone</SingleName> </PersonName> Content Models (Cont’d) DTD, by Dr. Khalil

  21. Consider the following BookCatalogBasic.dtd: <!-- ======= The BookCatalog DTD ('Basic' version) ======= --> <!ELEMENT BookCatalog (Catalog, Publisher+, Book*) > <!-- <Catalog> section --> <!ELEMENT Catalog (CatalogTitle, CatalogDate) > <!ELEMENT CatalogTitle (#PCDATA) > <!ELEMENT CatalogDate (#PCDATA) > <!-- <Publisher> section --> <!ELEMENT Publisher (CorpName, Website*, Address) > <!ELEMENT CorpName (#PCDATA) > <!ELEMENT Website (#PCDATA) > <!ELEMENT Address (Street*, City, Region?, PostalCode?, Country) > <!ELEMENT Street (#PCDATA) > <!ELEMENT City (#PCDATA) > <!ELEMENT Region (#PCDATA) > <!ELEMENT PostalCode (#PCDATA) > <!ELEMENT Country (#PCDATA) > <!-- <Book> and <Author> section --> <!ELEMENT Book (ISBN, Title, Author+, Editor*, Abstract?, Pages, Price, Subjects?) > <!ELEMENT ISBN (#PCDATA) > <!ELEMENT Title (#PCDATA) > <!ELEMENT Author (#PCDATA) > <!-- Just a placeholder for now --> <!ELEMENT Editor (#PCDATA) > <!-- Ditto --> <!ELEMENT Pages (#PCDATA) > <!ELEMENT Price (#PCDATA) > <!ELEMENT Subjects (Subject, Subject?, Subject?) > <!ELEMENT Subject (#PCDATA) > <!-- ======= END of BookCatalog DTD ======= --> An Example – ELEMENT Declaration DTD, by Dr. Khalil

  22. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE BookCatalog SYSTEM “BookCatalogBasic.dtd” > <BookCatalog> <Catalog> <CatalogTitle>The Wrox BookCatalog ('Basic' version)</CatalogTitle> <CatalogDate>2000-05-23</CatalogDate> </Catalog> <Publisher> <CorpName>Wrox Press Ltd.</CorpName> <Website>www.wrox.com</Website> <Address> <Street>Arden House</Street> <Street>1102 Warwick Road</Street> <Street>Acocks Green</Street> <City>Birmingham</City> <Region>England</Region> <PostalCode>B27 6BH</PostalCode> <Country>UK</Country> </Address> </Publisher> <Publisher> <CorpName>Wrox Press Inc.</CorpName> <Website>www.wrox.com</Website> <Address> <Street>29 S LaSalle St, Suite 520</Street> <City>Chicago</City> <Region>IL</Region> <Country>USA</Country> <PostalCode>60603</PostalCode> </Address> </Publisher> <Book> <ISBN>1-861003-11-0</ISBN> <Title>Professional XML</Title> <Author>Didier Martin</Author> <Author>Mark Birbeck</Author> <Author>Michael Kay</Author> <Author>Brian Loesgen</Author> <Author>Jon Pinnock</Author> <Author>Steven Livingstone</Author> <Author>Peter Stark</Author> <Author>Kevin Williams</Author> <Author>Richard Anderson</Author> <Author>Stephen Mohr</Author> <Author>David Baliles</Author> <Author>Bruce Peat</Author> <Author>Nikola Ozu</Author> <Editor>Jon Duckett</Editor> <Editor>Peter Jones</Editor> <Editor>Karli Watson</Editor> <Abstract>The complete practical encyclopedia for XML today.</Abstract> <Pages>1169</Pages> <Price>$49.99</Price> <Subjects> <Subject1>Internet</Subject1> <Subject2>Internet Programming</Subject2> <Subject3>XML</Subject3> </Subjects> </Book> </BookCatalog> An Example – ELEMENT Declaration (BookCatalogBasic.xml) DTD, by Dr. Khalil

  23. Element attributes are described using the attribute-list declaration (ATTLIST), with the standard syntax: <!ATTLIST elementName attrName attrType attrDefault defaultValue > Example: <!ELEMENT Book EMPTY > <!ATTLIST Book isbn CDATA #REQUIRED title CDATA #REQUIRED author CDATA #REQUIRED pages CDATA #IMPLIED price CDATA #IMPLIED > Attribute Types CDATA – Character data (simple data string). Enumerated value(s) – Attribute value must be one of a series that is explicitly defined in the DTD. ID – Attribute value is the unique identifier for this element instance. IDREF– A reference to the element with an ID attribute that has the same value as that of the IDREF. IDREFS – A list of IDREFs delimited by white space. NMTOKEN – A name token (a text string that conforms to the XML name rules, except that the first character of the name may be any valid name character). ENTITY – The name of a pre-defined entity. ENTITIES – A list of ENTITY names delimited by white space. NOTATION – Attribute value must be a notation type that is explicitly declared elsewhere in the DTD. Attribute (ATTLIST) Declarations DTD, by Dr. Khalil

  24. A DTD: <!ATTLIST AnElement its_attr CDATA #REQUIRED > A conforming instance: <AnElement its_attr=“some text string”> …</AnElement> ----------------------------------------- A DTD: <!ELEMENT Person (PersonName, FirstName, MiddleName, LastName, CorpName?, Email*, Biography?) > <!ATTLIST Person perID ID #REQUIRED > A conforming instance: <Person perID=“JHN_Q_PBLC” > <PersonName honorific=“Mr” suffix=“Jr” > <FirstName>John</FirstName> <MiddleName>Q</MiddleName> <LastName>Public</LastName> </PersonName> <CorpName>Acme XML Writers</CorpName> <Email>jqpublic@notmail.com</Email> <Biography>John, Jr. is a swell fellow, son of John, Sr.</Biography> </Person> A DTD: <!ELEMENT PersonName (FirstName, MiddleName, LastName) > <!ATTLIST PersonName honorific (Mr | Ms | Dr | Rev) #IMPLIED suffix (Jr | Sr | III) #IMPLIED > <!ELEMENT FirstName (#PCDATA) > <!ELEMENT MiddleName (#PCDATA) > <!ELEMENT LastName (#PCDATA) > <!ELEMENT Suffix (#PCDATA) > A conforming instance: <PersonName honorific=“Mr” suffix=“Jr” > <FirstName>John</FirstName> <MiddleName>Q</MiddleName> <LastName>Public</LastName> </PersonName> ATTLIST - Examples DTD, by Dr. Khalil

  25. The value of an ID attribute must be a legal XML name, unique within a document, and use the #IMPLIED or #REQUIRED default values. There may only be on ID attribute for each element type. The value of an IDREF attribute must be a legal XML name, and must match the value of an ID attribute within the same document. Multiple IDREFs to the same ID are permitted. Examples: <!ATTLIST Book author IDREF #REQUIRED > <Book author=“JHN_Q_PBLC” .. > ------------------------------------------------------------ <!ATTLIST Book author IDREFs #REQUIRED > <Book author=“JHN_Q_PBLC JN_D TW_PC” .. > ------------------------------------------------------------ ATTLIST (Cont’d) DTD, by Dr. Khalil

  26. #REQUIRED – The attribute must appear in every instance of the element. #IMPLIED – The attribute is optional. #FIXED (plus default value) – The attribute may or may not appear in the document. If the attribute does appear, it must must match the default value; if it doesn’t appear, the parser may supply the default value. #default value(s) – The attribute may or may not appear in the document. If the attribute does appear, it may be any value that matches those in the ATTLIST declaration; if it doesn’t appear, the parser may supply the default value. Attribute Defaults DTD, by Dr. Khalil

  27. <!-- ======= The BookCatalog DTD ('Expanded' version) ======= --> <!ELEMENT BookCatalog (Catalog, Publishers?, Persons?, Subjects?, Books?) > <!-- Generic PCDATA element types section --> <!ELEMENT Biography (#PCDATA) > <!ELEMENT CorpName (#PCDATA) > <!ELEMENT Email (#PCDATA) > <!ELEMENT Website (#PCDATA) > <!-- <Catalog> section --> <!ELEMENT Catalog (CatalogTitle, CatalogDate) > <!ELEMENT CatalogTitle (#PCDATA) > <!ELEMENT CatalogDate (#PCDATA) > <!-- <Publishers> section --> <!ELEMENT Publishers (Publisher+) > <!ELEMENT Publisher (CorpName, Email*, Website*, Address, Imprints?, Levels?) > <!ATTLIST Publisher pubID ID #REQUIRED isbn CDATA "??????" > <!ELEMENT Address (Street*, City, Region?, PostalCode?, Country) > <!ATTLIST Address hq (yes | no) "yes" > <!ELEMENT Street (#PCDATA) > <!ELEMENT City (#PCDATA) > <!ELEMENT Region (#PCDATA) > <!ELEMENT PostalCode (#PCDATA) > <!ELEMENT Country (#PCDATA) > <!ELEMENT Imprints (Imprint+) > <!ELEMENT Imprint (#PCDATA) > <!ATTLIST Imprint imprintID ID #REQUIRED > <!ELEMENT Levels (Level+) > <!ELEMENT Level (#PCDATA) > <!ATTLIST Level levelID ID #REQUIRED > An Example – BookCatalogExpanded.dtd DTD, by Dr. Khalil

  28. <!-- <Persons> section --> <!ELEMENT Persons (Person*) > <!ELEMENT Person (PersonName, CorpName?, Email*, Address?, Biography?) > <!ATTLIST Person perID ID #REQUIRED role (AU | ED | AE | IL | RV | unknown) #REQUIRED > <!ELEMENT PersonName (SingleName | (FirstName, MiddleName*, LastName)) > <!ATTLIST PersonName honorific (Mr. | Ms. | Dr. | Rev.) #IMPLIED suffix (Jr. | Sr. | I | II | III | IV | V | VI | VII | VIII) #IMPLIED > <!ELEMENT FirstName (#PCDATA) > <!ELEMENT MiddleName (#PCDATA) > <!ELEMENT LastName (#PCDATA) > <!ELEMENT SingleName (#PCDATA) > <!-- <Subjects> section --> <!ELEMENT Subjects (Subject*) > <!ELEMENT Subject (#PCDATA) > <!ATTLIST Subject subjectID ID #REQUIRED > <!-- <Books> section --> <!ELEMENT Books (Book+) > <!ELEMENT Book (Title, Abstract?, Prices?, SubjectRefs?) > <!ATTLIST Book bookID ID #REQUIRED isbn CDATA #REQUIRED publisher IDREF #REQUIRED authors IDREFS #REQUIRED editors IDREFS #REQUIRED imprint IDREF #IMPLIED pubDate CDATA "2000" pages CDATA "????" level IDREF #IMPLIED > <!ELEMENT Title (#PCDATA) > <!ELEMENT Abstract (#PCDATA) > <!ELEMENT Prices (Price+) > <!ELEMENT Price (#PCDATA) > <!ATTLIST Price currency (USD | GBP | CDN) "USD" > <!ELEMENT SubjectRefs (SubjectRef, SubjectRef?, SubjectRef?)> <!ELEMENT SubjectRef EMPTY > <!ATTLIST SubjectRef subject IDREF #REQUIRED > <!-- ======= END of 'Expanded' BookCatalog DTD ======= --> BookCatalogExpanded.dtd (Cont’d) DTD, by Dr. Khalil

  29. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE BookCatalog SYSTEM "BookCatalogExpanded.dtd" > <BookCatalog> <Catalog> <CatalogTitle>The Wrox BookCatalog ('Expanded' version)</CatalogTitle> <CatalogDate>2000-05-23</CatalogDate> </Catalog> <Publishers> <Publisher pubID="WRX_PRS_LTD" isbn="861003"> <CorpName>Wrox Press Ltd.</CorpName> <Email>feedback@wrox.com</Email> <Website>www.wrox.com</Website> <Address> <Street>Arden House</Street> <Street>1102 Warwick Road</Street> <Street>Acocks Green</Street> <City>Birmingham</City> <Region>England</Region> <PostalCode>B27 6BH</PostalCode> <Country>UK</Country> </Address> <Imprints> <Imprint imprintID="PRG2PRG">Programmer to Programmer</Imprint> </Imprints> <Levels> <Level levelID="BEG">Beginning</Level> <Level levelID="INS">Instant</Level> <Level levelID="PRO">Professional</Level> </Levels> </Publisher> <Publisher pubID="WRX_PRS_INC"> <CorpName>Wrox Press Inc.</CorpName> <Address hq="no"> <Street>29 S LaSalle St, Suite 520</Street> <City>Chicago</City> <Region>IL</Region> <PostalCode>60603</PostalCode> <Country>USA</Country> </Address> </Publisher> </Publishers> BookCatalogExpanded.xml DTD, by Dr. Khalil

  30. <Persons> <Person perID="DDR_MRTN" role="AU"> <PersonName> <FirstName>Didier</FirstName> <MiddleName>P</MiddleName> <MiddleName>H</MiddleName> <LastName>Martin</LastName> </PersonName> <CorpName>Talva Corp.</CorpName> <Biography>Didier PH Martin has worked with computers for 21 years.</Biography> </Person> <Person perID="DN_PRKR" role="ED"> <PersonName> <FirstName>Dianne</FirstName> <LastName>Parker</LastName> </PersonName> <CorpName>Wrox Press Ltd.</CorpName> </Person> <Person perID="DVD_HNTR" role="AU"> <PersonName> <FirstName>David</FirstName> <LastName>Hunter</LastName> </PersonName> </Person> <Person perID="JN_DCKT" role="ED"> <PersonName> <FirstName>Jon</FirstName> <LastName>Duckett</LastName> </PersonName> <CorpName>Wrox Press Ltd.</CorpName> </Person> <Person perID="JNTHN_PNCK" role="AU"> <PersonName> <FirstName>Jonathan</FirstName> <LastName>Pinnock</LastName> </PersonName> <Email>jon@jpassoc.co.uk</Email> <Address> <City>Hertfordshire</City> <Region>England</Region> <Country>UK</Country> </Address> </Person> <Person perID="KRL_WTSN" role="ED"> <PersonName> <FirstName>Karli</FirstName> <LastName>Watson</LastName> </PersonName> <CorpName>Wrox Press Ltd.</CorpName> </Person> BookCatalogExpanded.xml (Cont’d) DTD, by Dr. Khalil

  31. <Person perID="LS_STPHNSN" role="ED"> <PersonName> <FirstName>Lisa</FirstName> <LastName>Stephenson</LastName> </PersonName> <CorpName>Wrox Press Ltd.</CorpName> </Person> <Person perID="MRK_BRBCK" role="AU"> <PersonName> <FirstName>Mark</FirstName> <LastName>Birbeck</LastName> </PersonName> <Biography>Mark has been a professional programmer for 18 years.</Biography> </Person> <Person perID="NKL_OZ" role="AU"> <PersonName> <FirstName>Nikola</FirstName> <LastName>Ozu</LastName> </PersonName> <Biography>Nikola Ozu is a consultant who lives in Wyoming.</Biography> </Person> <Person perID="PTR_JNS" role="ED"> <PersonName> <FirstName>Peter</FirstName> <LastName>Jones</LastName> </PersonName> <CorpName>Wrox Press Ltd.</CorpName> </Person> <Person perID="STPHN_MHR" role="AE"> <PersonName> <FirstName>Stephen</FirstName> <LastName>Mohr</LastName> </PersonName> <CorpName>Omicron Consulting</CorpName> </Person> <Person perID="STVN_LVNGSTN" role="AU"> <PersonName> <FirstName>Steven</FirstName> <LastName>Livingstone</LastName> </PersonName> </Person> </Persons> BookCatalogExpanded.xml (Cont’d) DTD, by Dr. Khalil

  32. <Subjects> <Subject subjectID="INTRNT">Internet</Subject> <Subject subjectID="INTRNT_PRGRMNG">Internet Programming</Subject> <Subject subjectID="XML">XML (eXtensible Markup Language)</Subject> </Subjects> <Books> <Book bookID="PRFSNL_XML" isbn="1-861003-11-0" publisher="WRX_PRS_LTD" authors="DDR_MRTN JNTHN_PNCK MRK_BRBCK STPHN_MHR NKL_OZ" editors="JN_DCKT PTR_JNS KRL_WTSN" imprint="PRG2PRG" pubDate="2000-01" pages="1169" level="PRO"> <Title>Professional XML</Title> <Abstract>The complete practical encyclopedia for XML today.</Abstract> <Prices> <Price currency="USD">49.99</Price> <Price currency="GBP">35.99</Price> <Price currency="CDN">74.95</Price> </Prices> <SubjectRefs> <SubjectRef subject="INTRNT" /> <SubjectRef subject="INTRNT_PRGRMNG" /> <SubjectRef subject="XML" /> </SubjectRefs> </Book> <Book bookID="BEGNNG_XML" isbn="1-861003-41-2" publisher="WRX_PRS_LTD" authors="DVD_HNTR JNTHN_PNCK NKL_OZ" editors="DN_PRKR LS_STPHNSN" imprint="PRG2PRG" level="BEG"> <Title>Beginning XML</Title> <Abstract>The best practical tutorial for XML.</Abstract> <Prices> <Price>39.99</Price> <Price currency="GBP">28.99</Price> <Price currency="CDN">59.95</Price> </Prices> <SubjectRefs> <SubjectRef subject="INTRNT" /> <SubjectRef subject="INTRNT_PRGRMNG" /> <SubjectRef subject="XML" /> </SubjectRefs> </Book> </Books> </BookCatalog> BookCatalogExpanded.xml (Cont’d) DTD, by Dr. Khalil

  33. Limitations of DTDs • DTDs are not extensible (unlike XML itself). • Only one DTD may be associated with each document. • DTDs do not work well with XML namespaces. • Very weak data typing. DTD, by Dr. Khalil

  34. Thank you DTD, by Dr. Khalil

More Related