IGP:FoundationXHTML Guiding Principles

IGP:FoundationXHTML has been designed using a number of very practical digital content ownership and management requirements observed, defined and established over a decade of experience working with high-value content.

The practical requirements approach deliver instant value, and are able to delivery future value while significantly reducing the cost of ownership of digital content.

IGP:FoundationXHTML asserts that to implement a real and working digital content strategy there can be no separation of priority or importance between the seven digital content dimensions we consider. These dimensions are:

• Content structure
• Content semantics
• Content styling
• Content presentation
• Content behaviour
• Content processing
• Content metadata

All of these must be considered simultaneously in the design of any tagging patterns for valuable digital content.

1. Structure. In FX structure is king. This is the core value which defines the content stack and conditional grouping. It is best understood as the core accessibility value of the content when no styling or processing is applied. The core structure elements are XHTML/5. There is no reinvention or extension of the HTML; and the available HTML elements must be used with deep thought. Not all HTML web oriented elements and attributes apply for high future value digital content.
2. Semantics. Semantic names should only be used if the value is explicit and associated with a structural element. Semantics are always applied as qualifiers to structure. Using HTML as the base ensures it is not possible to create a tagging pattern where structure has to be implied from semantics. This approach prevents digital content "death by semantics". 
3. Styling. Styling is the layout, decoration or prettifying with CSS for increased understanding, user engagement, custom presentation or branding. It is important to understand that CSS is a very powerful tool that works with the XHTML on multiple dimensions. Styling is just one of those dimensions.
4. Presentation. In FX terms presentation means the "format" context from which a content presentation instance will be delivered. Eg: PDF, e-books, other formats, static sites, fixed and flow layouts, interactivity, CDP/ACO and remixed content. To the extent possible FX tagged content must always be available for any presentation context. Where content or tagging is created for a single or set of presentation contexts, the tagging must be explicit and obvious for those presentation contexts to both humans and processors through controlled grammars.
5. Behaviour. Modern digital content often has the requirement to exhibit behavioural characteristics in various contexts. FX must allow and enable required behaviour without reducing, siloing or hiding core content value. This includes the ability to be used with CSS modifiers such as transforms, transitions and animation; Javascript assisted interactivity; and flow/fixed/variable layout for a range of digital content reading devices, platforms and reuse environments.
6. Processing. Digital content of worth requires processing for many purposes. Defined machine processing instructions must be consistent to reduce processing costs and future processing costs to a minimum. FX should be created to ensure tagging patterns provide clarity to allow explicit processing to achieve any required result. IE. Processing is never a "leave it until later" option. FX must implicitly state what and how content is to be processed without ambiguity. Ideally every FX tag is a processing target.
7. Metadata. Metadata in the FX context is data about content. This can included descriptive, fixity, provenance, rights, third-party vocabularies and processing instructions. Comprehensive and correct metadata is required for all formats, but is essential to allow content to be processed and used correctly in multiple advanced delivery contexts such as SCORM, web pages, extraction and remixing environments. FX states metadata is more important than semantic tagging for the correct use and reuse of content, although there are structures (such as references) that can be tagged for metadata extraction directly from semantic selectors. However this is inevitably more costly than providing straight-forward metadata constructions.

Usability and Cost

1. Content must always be ready to generate outputs and be available to authorized users.
2. It must be easy to create, maintain and modify.
3. It must not require the services of expensive DTD / Schema maintenance.
4. Must deliver the lowest possible total cost of ownership for front list production, back list retrodigitization, long term storage and management and new and emerging business scenarios.
5. Frontlist and backlist production must converge and create the same XHTML output.
6. Content must always be ready to create outputs as formats, packages, transforms or extractions which are instantly business ready.
7. FX must be able to be continuously upgraded without loss of value of the digital content, ever.
8. Digital content must be able to be incrementally value added at any time.
9. FX must be spot customizable at a publisher, template or document level without compromising the seven core properties. IE. customization is an extension, not a modification.

XML and Content

1. The core XHTML must display coherent content correctly structured and sequenced without the application of any style-sheets or other processing.
2. It must work for print, e-books, online, content object strategies and multiple packages out of the box always.
3. Content rules are encapsulated in maintained tagging patterns, not DTD or Schema rules.
4. Tagging patterns must be consistent and maintained.
5. The tagging is complete and accurate for any given class or genre of content. There is nothing obvious to add or consider later.
6. It must address, structure, semantics, (interactive) behaviour, presentation options and processing instructions when and where required.
7. It must be naturally extensible and customizable at a low level of granularity.
8. Use selector inheritance structures to the extent possible to keep the rules to a minimum and content dynamics at a maximum.
9. FX blocks must be completely mobile, extractable and remixable and retain their structural and semantic value.
10. It must be very easy to understand. This means everything must be explicitly obvious and not trapped or hidden in "advanced" technology techniques or proprietary formats.
11. The tagging vocabulary must be clear and transparent to a first time user, even at the cost of verbosity. IE. Verbose tagging structures that explain themselves clearly are preferred. If contractions are used they are universal and immediately known.
12. There is preferably only be one way to do anything, but if there are alternative strategies the content value outcome must be the same.
13. Use structural inheritance to reduce and control the grammar. Eg: title-block-rw inside Chapter-rw is a chapter title block.

Technology

1. When required it must be able to work with the latest technologies natively.
2. It must be very easy to create and maintain processors for any use of the content.
3. It must be easy to extend and process to new HTML standards within the system itself or at processing time.
4. It must be forward looking and be ready or changeable for at least the next five years of new technology initiatives.
5. Content stability, integrity and correctness is more important than technology.

FX Design Construction Rules

FX is a processor optimized, human readible and modifiable XHTML file with specific construction rules to ensure predictability in processing. These are the rules and guidelines that Infogrid Pacific use in the construction of IGP:FoundationXHTML.

1. All class attribute names must be lower case except the one specifically nominated exception.
2. FX content is defined as any XHTML content contained between galley-rw elements. IE. Without galley-rw it is not FX.
3. The class attribute is not only used for styling. It is used to specify properties for all digital content dimensions. Where appropriate each class attribute is usable by multiple dimensions.
4. All standard HTML and HTML5 elements and attributes can be used. There are no restrictions. There is a recommend "use element" list, and a recommended "don't use element" list where: a) HTML semantic elements do not have sufficient precision for long-term content management; b) the definitions are poorly expressed; or c) elements are web oriented.
5. Every class name must have the indentifying suffix -rw applied without failure, or an alternative custom suffix which is used consistently within a production environment.
6. Class names can be used to indicate structure, semantics, styling, presentation, behaviour and processing instructions. A class name should do only one thing and there must be no semantic ambiguity.
7. There is no limit to the number of class names that can be applied to an element.
8. Only controlled section class names can start with capital letters. If they are multi-word constructs they must be constructed in CamelCase. Section names must not contain  underscores or hyphens except for the -rw suffix.
9. Do not use cryptic or terse class names. Express names fully. Only unambiguous and commonly used abbreviations are acceptable. Eg: para, cols.
10. Do not rely on synonym terms. Explicit and precision use of class names increases content value.Eg: an image, illustration, figure and map are all different media genres.
11. Do not express acronyms used in a class name in uppercase. They must follow the lowercase rule. Eg: toc.
12. FX does not restrict the use of custom class names. Custom class names must never use the -rw suffix. Choose a project or publisher suffix to clearly differentiate them from the core FX controlled vocabulary. The suffix is ideally limited to three letters.
13. Publishers or organizations extending FX should use a consistent suffix and control their own vocabulary extensions. Eg: flow-control-abc.
14. Defined font-families (those not using font names) are to be defined using CamelCase, alphanumeric characters only and must not have the -rw suffix.
15. Class names should be built taxonomically where possible using only hyphens to separate the construction. This assists sorting, grouping, organization and processing operations.
16. Structural components and blocks should always have the primary group classifier element. Eg: block-rw, media-rw, layout-rw, etc.
17. No namespaces are to be used in FX ever. It is  not required and introduces (at least conceptually) externally controlled vocabulary elements.
18. An FX file must be complete and self-contained and a standard XHTML or XHTML5 file.
19. Where possible the FX package file should be a single file.
20. Where an FX file is stored as multiple files, these are assembly sequence referenced from the package manifest file.
21. FX must always be well-formed. It must be valid XTHML5. It does not have to pass accessibility tests (that is a processed output issue).
22. New genres or major structure tagging patterns must be approved, documented and have full functional test cases before they are implemented or used.
23. The HTML5 data- attribute can be used. Infogrid Pacific use the construction data-rw- to define all FX data attributes. Eg: data-rw-edit-date="2011-01-01".