IGP:FoundationXHTML Overview

Tagging accuracy, consistency and quality is fundamental to high value XML content production of any kind. If this can be maintained across a wide range of content types, and over time, then the long term value of content increases immeasurably.

It is reasonably true to say that there are few organizations that have been able to maintain large collections of XML that are seamlessly reusable across years (mainly in academic publishing). By design, IGP:FoundationXHTML gives any organization just such an XML strategy. But it uses XHTML.

Then and now

DocBook, TEI, NLM and most custom XML systems focus on describing the content and letting someone create a processor for it in the future. The XML strategy is effectively detached from any reuse scenario generally with an argument for semantic purity. This approach is meant to deliver the most future-proof content. The argument is wrong and used very inconsistently.

The textbook publishing majors have created many XML schemas with highly complex components and strategies for rendering complex layout. After more than a decade of work, there are none using XML for all their documents, and those who have tried cannot reliably use their legacy XML easily.

Something is wrong in XML land!

Just having the content in XML with a promise of something in the future is not enough for future value content scenarios. The reliable processability, consistency, instant remixability and long-term trustworthiness are the real content business drivers with digital content.

Descriptive XML schemas do not provide that, and even worse, the simple descriptive methods have changed radically over 10 years. DocBook created in 2000 will have radically different capabilities (fewer) to DocBook produced in the current version 5. Add to this that DocBook is generally unworkable without customization and there is an inevitable content strategy collapse.

Too many publishers say our content is XML so everything is OK, but they never process that content.

When descriptive XML DTD/Schema files are processed to XHTML (which they always have to be) they are effectively taking a constrained XML and making a dumber XHTML. This is not what content owners need.

The need is for digital content to be very smart, and deliver consistently.

Change is essential for future value

Hence the urgent need to change to new digital content XML approaches. XHTML hasn't changed in a significant manner for a decade. XHTML5 the emerging future standard supports all legacy XHTML and extends it with new dynamic functions that will increase the value of digital content further. Most importantly XHTML is not over-defined and rigid at the descriptive level making it the perfect vehicle for current and emerging requirements for a wide range of content types.

IGP:FoundationXHTML uses standard XHTML elements with a defined and highly controlled set of class attributes with multiple values, to do the job that would normally be done by XML nested elements and attributes and values. These core styles are supported by comprehensive IDs which have an important role in format processing and other post processing requirements.

FX also uses structural inheritance very strongly to reduce the verbosity of common structural items. For example an Ordered List <ol> inside a <named list>, becomes that type of list. This approach is amazingly powerful in processing and content reuse. It is never seen in verbose XML land.

The immediate value of this approach is that content structure is outlined by a set of well known major XHTML elements (eg. <div><h1-h6><p><ul-ol>), that are immediately useable in a wide range of contexts. These are then further refined by the addition of multiple CSS selectors which establish any level of descriptive nuance on a global or project specific basis.

The files are instantly available for viewing and use in any browser and on most devices. Processing capability is reinforced by the use of XHTML, which makes the files fully accessible to standard XML/XSL processing techniques, as well as by more flexible and lower ownership cost CSS-3 processing methods.

Excellent PDF generation from applications such as PrinceXML add sophistication to the solutions to take over from expensive to own and operate desktop publishing programs that systematically destroy content future value.

Strict grammar control and discipline is required to make a multiple class attribute strategy work effectively. That is done primarily by a production environment that enforces the rules with valid tagging patterns and is simpler and lower cost to implement than validating XML. More importantly, with easily available tools it opens the creation and maintenance of the XML.XHTML to non-XML experts.

Document Structures

The FX document structure is deliberately as flat as possible. It eschews section nesting except where it is a specific property of the content. This alone significantly reduces cost of creation and maintenance. If nested sections are required for document sub-sections they are processed from serial named <div> elements to nested <div>structures. This is trivial processing. For example chapters are not nested inside parts, and within chapters, multi-level headers are not nested.

It is a philosophical argument beyond the scope of this document whether sections are conceptually nested, or whether that is an artificial contrivance for technologies sake. Either way the outcome is the same.

Nesting is seldom needed in presentation in any environment, and when it is, it is relatively easy to process to nested sections as part of a specific processing operation rather than demand that every output processor must always create nested conditions and expand the DOM tree excessively.

FX uses the XML element set defined by XHTML 1.0 and is not expanded to use relevant HTML5 elements.  Using custom extensions reduced the flexibility and value of the XML in the same way that custom extensions in DocBook or TEI effectively turn those so-called "Standard" Schemas into custom XML.

Using the base XHTML structures ensures the highest default compatibility with CSS, Javascript and e-pub (e-book format), and reduces additional processing requirements for moveable structures and linking.

FX does apply some usage rules, guidelines, and sometimes constraints on the XHTML elements, especially for generic elements such as <sub>, <sup>, <img>.

The basic FX document is:

<div class="galley-rw">
   <div class="body-rw SectionLabel-rw">
      <div class="defined selectors"> ... </div>
      <ul> ... </ul>
      <ol> ... </ol>
      <table> ... </table>
      <h2-h6> ....</h2-/h6> 
      <p> ... <span class="defined selectors"> ... </span> </p>
   </div>
</div>

Obviously there are a few more options than this, but with a sophisticated, maintained and controlled CSS selector grammar, FX can achieve everything more complex DTD's can, and many things they cannot due to restrictions imposed by DTDs. FX is also considerably more economic in terms of text character count, a significant issue with mobile delivery being the primary near future transport mechanism.

Block structures

Any XML for document production, processing and representation is relatively sophisticated and must cover complexities from simple text throught to complex print layout. This is very difficult to do with so-called semantic XML strategies such as DocBook and custom XML schemas, which are sketchy in many areas and can require the constant changing and revision of tagging strategies, schemas and processing components.

FX block structures are possibly more complex (sophisticated) than many other systems as they are designed for specialist processing, styling, extraction and presentation. Processing is not something that is left until later, it is part of the design process, so every element and attribute is matched with a processing option across multiple formats.

FX makes heavy use of multiple XHTML class attributes. It can look like this:

<p class="attribute1 attribute2 attribute3 attribute4"> ...</p>

There is sometimes a misunderstanding that CSS class selectors are restricted to document styling, but XHTML imposes no such rule. Class selectors are just another XHTML attribute/value combination and use the term "class" as much for objectization in a programming sense, as for handles to apply styles. FX uses this core XML fact to use class statements as both semantic descriptors and processing instructions where necessary.

This is a core strength of XHTML that is not available in standard XML. General wisdom in XML is to use elements rather than attributes as attributes are hard to maintain. Also attributes cannot contain multiple values, but elements can contain multiple attributes. This results in silly grammar spawn. Standard XHTML methods and processing encourages the use of multiple attributes in the class attribute.

FX uses heirarchies of class attributes, plus specific implied or explicit selectors for various format processing requirements. The end result is an easy to tag XML with very high levels of usability at multiple levels, and an XML that is easy to interprete predictably. 

Take for example a simple block extract.

<div class="block-rw extract-rw"> .... </div>

This has two attribute values, the first the generic block selector describes to the processing system that this is a structured content block that is in the primary flow and needs distinctive processing. It is also a general processing and extraction target. For example all block-rw's could be hidden with a simple CSS style, or extracted, processed and styled collectively.

The second selector gives a semantic label to the structural component saying what type of block it is.The sub-set extract-rw is available for separate evaluation and processing.

This can be extended for custom books for specific styling needs. Example:

<div class="block-rw extract-rw shakespeare">

This is more descriptive and can have significantly different or additional processing applied. It can be used for styling, or identification. The additional attribute value does not disturb the structural and semantic value of the block, but immediately adds metadata classification value.

This is a very important concept to grasp. Attribute customization can be applied immediately to any content without undermining or disturbing the core structural and semantic value of the XHTML. The custom extension will only come into play if processors and presentation environments can use it. 

FX also uses selectors to define processing tasks, where this is appropriate. The following example is a Numbered figure which is floated. 

<div class="media-rw figure-rw float-top-next-rw float-galley-center-rw 
      width80-rw">
   <img>....</img>
   <p class="caption-rw">.... </p>
</div>

In this example there are five selectors. The sequence is for human consumption and grammar control. Processors treat each selector independently for evaluation.

The structural identifier is media, the semantic identifier is a figure. By definition a figure is numbered in FX therefore the caption has numbers and the descriptor generated automatically (eg. Fig 1.1. ) and it can also be processed to appear in a generated List of Figures).

This is followed by processing instruction selectors that tell an processor or device how the media block should be presented in various formats. These selectors give processors the message, "If you know how to do it, this media block should be floated to the top of the next page, place it in the center of the galley and make it 80% of the galley width". 

The float-next-top is a specific print or paginated output instruction, or for a renderer capable of handling pagination (float to the top of the next page doesn't make a lot of sense in a scrolling environment!).

In IGP:Digital Publisher Formats on Demand the appropriate print selectors are automatically removed by the format generators and the CSS modified for the capability of the various formats, but the original print layout intention remains in the master XHTML.

Primary Structural Selectors

An FX element that contains class attributes must use a primary structural selector, should have a semantic selector and may have custom and processing selectors.

The primary section structural selectors that define the build-up of a document, irrespective of its application or use are:

1. galley-rw
2. frontmatter-rw
3. body-rw
4. backmatter-rw

A structural selector is similar to a section in physical document, but has wider purposes in the FX model

galley-rw

galley-rw has a single use. It defines the extent of an FX document or FX document fragment independently from any surrounding XHTML or HTML. It can be inserted into any other document and be expected to behave reliably. It can be inserted with or without the stylesheet components. It can be processed reliably by a processor.

Therefore any content that is sourced from FX for any purpose MUST have <div class="galley-rw"> ... </div>

This element is immutable and cannot and must not be extended with additional class attributes.

Section identifiers

The nature of section identifers is processing instructions for presentation, harvesting and reuse mobility. By using precise semantics rather than nested inheritence, non-specific names or other XML mechanism, their purpose is instantly identifiable. They can be targeted for use, reuse and presentation processing instantly.

Section identifiers are ALWAYS immediately inside the galley-rw statement. The following example shows the full expression for a chapter.

<div class="galley-rw">
   <div class="body-rw Chapter-rw">
   </div>
</div>

frontmatter-rw

SeriesTitle Half-Title BookTitlePage Copyright Copyright-Alternative Dedication Epigraph Contents ListOfFigures Preface Foreword Introduction

Any section of a book is a major XML wrapper and capable of being extracted and manipulated independently.

<div class="frontmatter-rw BookTitlePage-rw">

The frontmatter selector is always lower case. The section selector is always Camel case to allow it to be space processed and used in a human interface context such as generated tables of content in various formats.

Front matter or preliminaries is a publishing concept and applies to publisher type content, but can also be applied to corporate and other content types as well.

In publisher print output books, page counters often use lowercase roman numerals for frontmatter sections. If counters are being used then the page number format can be set for frontmatter. In e-books frontmatter sections are often supressed or moved to a new position.

body-rw

Part PartContinue Chapter ChapterContinue Article ArticleContinue Topic TopicContinue Lesson LessonContinue Section

All complete documents require body sections. FX makes nothing mandatory as it can be very useful to process FX to create a new document which is a library of title pages (for example).

backmatter-rw

Appendix References Notes Bibliography Index

The standard back matter parts for publishing and corporate documentation are supported as standard structural items.

Primary foundation content block selectors

To allow flexibility in processing and production, FX Content Blocks are created into groups with common properties by document usage, or document type. The current defined groups are:

1. title-block-book-rw
2. title-block-rw
3. metadata-rw
4. block-rw
5. media-rw
6. para-rw
7. list-rw
8. table-rw
9. layout-rw
10. poem-rw
11. drama-rw
12. equation-rw
13. QAA-rw
14. format-processing-instructions-rw

Note that special content forms such as poetry, drama, equations and questions and answers have been given the value of a group selector. This is because they are of structural significance in their own right and do not fall into the concept of a standard text oriented document. There are other examples in the FX Genres and Extensions tagging patterns.

Conclusion

Each Structural Selector or Group Selector has a set of semantic selectors for its particular requirements and only has to be introduced through templates where a document requires them. This makes maintaining and use of a large library of tagging patterns for a wide range of content genres easy with a divide and conquer approach.

The list of semantic selectors is considerably larger, than the primary structural selectors and is dealt with in detail in each section of this document. There it clearly shown where and how Infogrid Pacific have defined each document part and type for actual use in a real digital-content world.