In: Categories » » HTML XHTML and CSS » XML DTD Modules Part Two
.mix The .mix suffix creates lists of elements for use in content models in which different classes of items get combined. The Flow.mix entity (also from the customization file of XHTML 1.1 - Module-based XHTML) is a good example:
<!ENTITY % Flow.mix "%Heading.class; | %List.class; | %Block.class; | %Inline.class; %Misc.class;" >
Any element that uses Flow.mix within its content model can include just about any element in the XHTML vocabulary. It's definitely a combination.
.mod Parameter entities that end in .mod assemble complete DTDs out of all of these little parts that comprise XHTML. XHTML 1.1's driver file (included as Appendix B of XHTML 1.1 - Module-based XHTML) contains lots of these entities.
<!ENTITY % xhtml-form.mod PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Forms 1.0//EN" "xhtml11-form-1.mod" > %xhtml-form.mod;
In this case, the entity is declared using a public identifier and a system part. If the application or parser processing this understands the public identifier, it can use that information to include the DTD. If not, it can use the relative URL that follows to retrieve the file. After the declaration, the contents of the file are immediately included in the DTD.
.module Parameter entities that end in .module turn the entities that end in .mod on and off using the same conditional statements (INCLUDE and IGNORE) that .attlist entities use. For example, the XHTML form module normally gets loaded because of this code:
<!ENTITY % xhtml-form.module "INCLUDE" > <![%xhtml-form.module;[ <!ENTITY % xhtml-form.mod PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Forms 1.0//EN" "xhtml11-form-1.mod" > %xhtml-form.mod;]]>
If you want to keep the form module from loading, all you have to do is define a new xhtmlform. module entity before that one, overriding it with a value of IGNORE:
<!ENTITY % xhtml-form.module "IGNORE" > ... <!ENTITY % xhtml-form.module "INCLUDE" > <![%xhtml-form.module;[ <!ENTITY % xhtml-form.mod PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Forms 1.0//EN" "xhtml11-form-1.mod" > %xhtml-form.mod;]]> The result is this: <![IGNORE[ <!ENTITY % xhtml-form.mod PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Forms 1.0//EN" "xhtml11-form-1.mod" > %xhtml-form.mod; ]]>
The module doesn't load. Note the naming convention here – both the entities (.mod and .module) have the same name except for the suffix. This makes the DTDs much more manageable.
Schema Modules XHTML 1.1 will use XML Schemas when they're ready. The Modularization of XHTML draft's Appendix A states, "This appendix will contain implementations of the modules defined in XHTML Abstract Modules via XML Schema [XMLSCHEMA] when the XML Schema becomes a W3C approved recommendation." The Building XHTML Modules draft doesn't specify how to build Schema modules. The current Schema drafts don't use mechanisms that correspond directly to parameter entities, but similar approaches may be possible using general entities (because Schemas are XML documents themselves) and the extension and restriction mechanisms of XML Schemas.
Putting XHTML 1.1 Together For now, XHTML is assembled using the parameter entities and DTD modules just described. XHTML 1.1 - Module-based XHTML includes a driver file and a customization file that handle the formal integration, as well as a set of rules for XHTML 1.1 conformance. Much of the work done in XHTML 1.1 - Module-based XHTML builds on the work performed in the other drafts, incorporating them by reference without describing what's happening.
Tip While XHTML 1.1 - Module-based XHTML doesn't describe XHTML in the same kind of detail that HTML 4.01 (or even XHTML 1.0) specifications do, it includes a convenient description of how this flavor of XHTML 1.1 differs from XHTML 1.0 (http://www.w3.org/TR/xhtml11/changes.html#a_changes). If all you want to do is create XHTML 1.1 documents that conform to the main XHTML 1.1 specification, you just have to use the DOCTYPE declaration listed here and make sure your documents validate:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
If you work with XHTML 1.0's strict vocabulary, you probably won't have any problems. But note that XHTML 1.1 omits substantial portions of the transitional and frameset vocabularies. The W3C probably will create additional profiles based on the same XHTML 1.1 modules. The XHTML Basic specification, for example (http://www.w3.org/TR/xhtml-basic), defines a much smaller profile of XHTML 1.1 and requires that you use a different DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
XREF The specification for XHTML Basic is available at http://www.w3.org/TR/xhtml-basic/. Many users will find these profiles suffice, but developers who build their own modules and need to integrate them with the rest of XHTML must build their own profiles. Following the examples of XHTML 1.1 and XHTML Basic, you should do this through the creation of a driver file and a customization file plus a Formal Public Identifier (FPI) that identifies the driver file.
Note The XHTML profiles provided by the W3C include SGML Open Catalog entries in addition to FPIs, but it isn't clear from the drafts whether Open Catalog entries are required or optional parts of XHTML modularization projects. For more on how to build SGML Open Catalog entries, see http://www.oasisopen. org/html/a401.htm. The Formal Public Identifier is the easiest part to create. FPIs contain four fields, separated by doubleslashes (//). The first field is always a dash, unless the resource the FPI describes is created by a formal standards organization such as ISO. (If the FPI is created by a standards organization, this field identifies the standard to which it refers.) The second field contains the name of the organization maintaining the resource. For the XHTML specification, this is W3C. For your own FPIs, it should be an identifier for your organization – possibly a domain name. The third field contains a unique name, chosen within your organization, which describes the referenced resource and includes version information as well. The final field should contain a language identifier (from the list in Appendix C). The language identifier describes the language within the resource and doesn't place any limitations on the content of documents using it. For example, the FPI for XHTML 1.1 is this:
-//W3C//DTD XHTML 1.1//EN
The first field is a dash (-) because the W3C is technically a vendor consortium, not a standards body proper. The second field contains W3C, the identifier used by the World Wide Web Consortium (W3C). The third field identifies the resource as a Document Type Definition (DTD) for XHTML 1.1. If the DTD changes for version 1.2 or 2.0, the W3C can change the version number within the FPI. Finally, EN identifies that the descriptions used in the DTD are written in English. (If the W3C provides a French translation, it might be FR. But French-language documents can refer to the English DTD without any problem.) Creating your own FPIs is easy. First (unless you work for ISO), start with a dash. Then identify your organization, followed by your project, followed by the language in which the DTDs are written. For example, if I create a profile that describes "Simon's Markup Language" version 1.0, the FPI might look like this:
-//simonstl.com//DTD SimonML 1.0//EN
Profile creators also should support a system identifier, typically a URL, where you can retrieve the DTD or other resource. Then the combination of the public and system identifiers is used in the DOCTYPE declaration by documents using the profile:
<!DOCTYPE simonML PUBLIC "-//simonstl.com//DTD SimonML 1.0//EN" "http://www.simonstl.com/xhtml/chap15/simonML.dtd">
The system identifier should refer to the driver file for the XHTML profile, just as the identifiers for XHTML 1.1 and XHTML Basic refer to their driver files. Driver files contain comments describing the module, a few entity declarations, and then an entity declaration that references and includes the customization file. After the customization file is included, the rest of the modules that make up the DTD are included using the .mod and .module parameter entities just described.
XREF Article 16 describes creating your own driver and customization files. It isn't clear quite how the W3C expects these files to fit into Web infrastructure. While XML processors routinely load resources like DTDs from across the Internet, that approach hasn't been used for the most part with HTML processors. Most likely, the W3C expects processors to use the FPI in the DOCTYPE declaration to figure out what they have to work with, and then apply logic specific to that document type rather than generic XML validation and processing. Because DOCTYPE declarations require a URI in addition to the FPI, however, ordinary XML processors will be capable of processing documents using the information retrieved from that URI. SGML Open Catalog entries (also provided in the XHTML specifications) provide another way for generic XML processors to interpret the FPI and retrieve the needed information.
legal notice
Our website is not responsible for the information contained by this article. Web-articles is a free articles resource.
Suggestion: If you need fresh, daily updated content for your website, feel free to use our service. Click here for more information.
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above.
related articles
Processing instructions XML also enables developers to pass information to the application through processing instructions (often called PIs). Processing instructions use a similar syntax to the XML declaration, although the rules for them are much less strict. Processing instructions begin with <? and end with ?>, but the developer generally dictates their contents. The first bit of text before a space appears in a PI is called the target. The target must start with a letter, unde...
2. lang Internationalization
Internationalization: xml:lang and lang Internationalization (often abbreviated i18n because 18 characters appear between the i and the n) gets a significant boost with the shift to XML primarily because of XML's use of Unicode as the underlying character model. While not every document needs to encode Chinese, Cyrillic, Arabic, and Indian characters, Unicode makes it possible for all of these forms to exist within a single document. In addition, XML and XHTML allow for the possibility of other e...
3. Anatomy of an XHTML Document
The transition from HTML to XHTML will come with a fair number of bumps. While later chapters introduce tools to help you get past those bumps – and figure out where they come from – this chapter examines what's going to change and demonstrates a few strategies for handling those changes. Along the way, we visit the ghosts of browsers past and explore problems that exist in current browsers. In turn, you discover how prepared and unprepared various tools are for XHTML. Note Som...
4. Converting to strict HTML and XHTML
Converting to strict HTML You start out by declaring your intentions to use the strict HTML 4.01 DTD by putting the appropriate DOCTYPE declaration at the head of the document: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Now the first section of the document, including the HTML opening tag and the HEAD element and its contents, is fine except for one line. The SCRIPT element no longer supports a LANGUAGE at...
5. Reading the XHTML DTDs A Guide to XML Declarations
Reading the XHTML DTDs: A Guide to XML Declarations Although the W3C has long had document type definitions (DTDs) for HTML, few developers actually use those DTDs as a foundation for learning HTML. XHTML 1.0 simplifies those DTDs with the slightly friendlier XML syntax – they previously used SGML's more complex syntax – and the increased emphasis on validation may lead developers to explore them more closely. Making good use of XHTML 1.1 requires some level of ...
6. Defaulting attribute values XHTML DTDs
XML 1.0 also provides a set of tools for specifying what happens if an attribute isn't declared within an element. Four different possibilities exist, including "the attribute just isn't there"; "the attribute must be there, period"; and "the attribute has this value, period." You already have seen a few uses of these choices in the preceding declarations. In the img element, for instance, the src and alt attributes are required (#REQUIRED); meanwhile, most of the rest of its attribute content is optio...
7. Exploring the XHTML DTDs
Exploring the XHTML DTDs Choosing Your DTD XHTML 1.0 provides three DTDs that describe different sets of XHTML elements and reflect the three choices provided in HTML 4.0: strict, transitional, and frameset. The probably the one that the W3C would like to see developers adhere to, but transitional DTDs reflect the reality of HTML usage much more accurately. Appendix A lists the in the three different DTDs, along with notes regarding attributes. To identify the DTD for a ...
8. Building XHTML DTD Structure Element and Attribute Declarations
Building Structure: Element and Attribute Declarations After all of these preliminaries, it's finally time to make some real declarations, creating the elements and attributes partly described by the entities established so far. This portion of the DTD is broken down into segments that reflect groupings of element types, foreshadowing to some extent the modularization process that XHTML 1.1 will perform. If you have trouble getting your XHTML documents to validate, you need to explore this portion of the ...
9. Style Sheets and XHTML
Cascading Style Sheets (CSS) is an enormously powerful tool that has been slow to catch on in the HTML development world. Whether or not you use (or like) CSS, the continuing evolution of CSS is deeply intertwined with the work moving forward on XHTML so learning about CSS can help you understand XHTML as well as implement it. Fortunately, CSS isn't very difficult once you master a few key structures and learn to apply its vocabulary. There are some real problems with existing CSS implementations that I cover later...
10. Formatting Content with CSS Properties
While selectors do a great job of picking out content that needs formatting, designers (as opposed to Web site managers) like CSS mostly because of the large number of available formatting properties. CSS offers properties that support nearly any presentation of a document desired, and yet more properties are in development as part of the CSS3 activity. CSS properties enable you to describe precisely how you want the pieces of your document formatted and to override the rules by which HTML is presented normally. <...