ZedAI Architecture Overview
From zedwiki
This document provides an overview of the architecture of the ZedAI framework.
Baffled readers may wish to consult the Terminology page.
Note - as of May 2009, this document is in need of updates
Contents |
Profiles: the basics
The ZedAI framework defines a method to compose XML grammars. These XML grammars are referred to as Z39.86 Authoring and Interchange Framework Profiles (Profiles for short).
A Profile is a complete document model that has been tailored for markup of a particular content type. Typical examples of profiles include:
- Book Profile
- Poetry Profile
- Drama Profile
- News Feed Profile
- Magazines and Journals Profile
- Consumer Medical Information Profile
By design and with intent, the ZedAI framework does not require any particular scope of a Profile; as exemplified above, a Profile can have a wide scope (such as a Profile created for markup of a wide range of print books) or it can have a narrow scope (such as a Profile created only for markup of consumer medical information).
Each profile has an associated Resource Directory, which lists normative and informative resources that are associated with the Profile. Such resources inlude schemas, stylesheets, RDF vocabularies, end-user documentation, etc. Resource Directories are readable by both humans and machines.
Each profile has a unique URI associated with it, which serves as the Profiles identifier. This URI also resolves to the Profiles Resource Directory.
Each profile is versioned, and so is its Resource Directory.
Profile Components
Each Profile is comprised of two main parts:
- the Profile Core Grammar
- zero or several Optional Features
Profile Core Grammar
A Profile Core Grammar defines the fundamental document model of the Profile. It is rich enough to be used as-is for markup of a large proportion of the typical content passing through a republishing house.
A Profile Core Grammar is composed in compliance with the rules of the W3C XHTML Modularization 2.0 framework. A Profile Core Grammar is typically built using schema modules from W3C XHTML 2.0 space and from Z39.86 space, although the specification does not impose any limitations here.
Cross-Profile Core Grammar Predictability
By being compliant with the XHTML Host Language Document Type Conformance definition of the W3C XHTML Modularization 2.0 framework, each Profile Core Grammar is required to include a set of modules, such as the fundamental Document module. This provides a basic document model predictability aspect across profiles. The ZedAI framework then adds additional required modules and patterns to be used in a Profile Core Grammar on top of those at the W3C level, to further enhance the cross-profile predictability. Such Z39.86-level requirements include
- Head metadata
- Common Attributes
- External Object inclusion
In addition to this, there are several inclusion patterns that are defined as good practice guidelines for Profile Core Grammar composition (they are not enforced in order to allow the widest possible theoretical document model variation). Such good practice inclusions include:
- The consistent reuse (and subsetting and/or extension, where necessary) of XHTML2 Text and Structure modules where applicable
- The consistent reuse (and subsetting and/or extension, where necessary) of Z39.86 Text and Structure modules where applicable
- In particular, allowing the W3C Role Module in the body context, coupled with additional Vocabularies when new information type domains are added
- In particular, allowing the W3C RDF/a Module in the body context
In relation to the theme of predictability however, the most important aspect of developing a Processing Agent for the ZedAI framework that can handle multiple profiles economically, is to implement using a pattern of module-wide behavior instead of document-type-wide behavior, as was possible in the days of monolithic static document types.
As an example, an XSLT transformation to go from a ZedAI profile to DocBook would be built using a set of XSLT modules, each corresponding to a schema module of the input grammar. In the XSLT driver, templates would be overridden where necessary (to correlate to schema drivers overriding patterns in schema modules).
Processing Agents may also make use of RDF-based fallback behavior discovery, since a Profile may through its Resource Directory give access to an RDF taxonomy that provides mappings between lesser-known QNames and well-known QNames.
Profile Optional Features
As opposed to a Profile Core Grammar, an Optional Feature is not a complete document model, but an optional Profile "addon". In other words, a Profile Core Grammar provides the document model, into which an Optional Feature is injected.
Although its not a specification requirement, an Optional Feature typically adresses a content type which is highly specialized, and therefore requires highly specific associated behaviors in Processing Agents[1].
Typical examples of Optional Features include:
- Mathematics
- Chemistry
- Music
- Interactive testing
- Content Selection (see for example DISELECT)
An Optional Feature is by design available for injection into more than one profile (for example, a Mathemathics Feature can appear in both a Book and a Journals profile (where the latter applies to the case of scientific journals). Several features can be used simultaneously in document instances (for example, using a Mathemathics and a Chemistry feature concurrently within a document adhering to a Book profile).
An Optional Feature is built using the same set of fundamental modularization rules as the Profile Core Grammar. It may reference modules from the Profile Core Grammar. There is no restriction on namespace usage (except the global rule that the null namespace must not be used).
Sometimes an Optional Feature contributes just one schema module. But it can contain several modules, and it can also provide normative and informative prose. It can also (indirectly via the Resource Directory) contribute role taxonomies[1]. Minimally, a feature must consist of one schema module.
Each feature has a Resource Directory, just like the profiles do.
Each feature is versioned, and so is its Resource Directory.
Optional Features and Document Model Predictability
Regardless of in which profile an Optional Feature appears, its document model and behaviors are static. This means that a Processing Agent can implement support for an Optional Feature in one generic way, and activate the behaviors associated with the Optional Feature when encountering it, regardless of Profile context.
In other words: when a Profile maintainer elects to include an Optional Feature in a Profile, the maintainer must not modify the internals of the feature, with the exception of modifications that are explicitly allowed in the Optional Features normative prose. (Example: injecting a Common attribute collection.)
Combining Core Grammars and Optional Features
The agency maintaining a Profile is in charge of determining which Optional Features are allowed to be used in conjunction with the Profiles Core Grammar. Note that this means that the number of Optional Features that can be used in a particular Profile ranges from zero to many.
The following rules distinguish Optional Features from Core Grammar modules at the schema level:
- The feature itself does not define the integration into the host document model. The host itself is in charge of this, and must at integration time obide to any integration rules defined by the Optional Feature. (Through this rule, we assure that Optional Features can be reused as-is between Profiles, and that the Optional Features topology remains static).
- A feature can not subset the host document model; it can only extend it. (Through this rule, we assure that the presence or abscence of an Optional Feature in a document instance is transparent in that the Core Grammar document model remains the same)
Normative and Informative Schemas
A Profiles normative schema (a.k.a. the Profiles "driver") includes all allowed Optional Features for the particular Profile. This means that the Profiles normative schema is a "super schema" that will validate all combinations of applicable features added to the profile in an instance document.
The Profiles maintainer may elect to generate informative "utility" schemas from the normative super schema, that includes typical content type cases.
Example: a normative schema is composed thusly:
Book Profile + Mathemathics Feature + Chemistry Feature + Music Feature
... from which the following informative schemas are generated:
- Book Profile only
- Book Profile + Mathemathics Feature
- Book Profile + Mathemathics Feature + Chemistry Feature
- Book Profile + Music Feature
The informative schemas are listed alongside the normative schema in the profiles Resource Directory. Users may use the normative schema during production, but are likely to prefer the informative subset schemas, as they provide a more scoped and therefore more effective schema. (When marking up a music book, one does not want to constantly be exposed to the option of adding chemical formulae.)
Document Instance Identity Declaration and Conformance
Each ZedAI document instance declares which Profile it complies with. It also declares which Optional Features it includes, if any. (Remember that the Profile defines which Optional Features may be used.)
The declaration is made in the head element, and uses syntax as in the following example of a document compliant with a "Book" profile, using a Mathematics and a Chemistry optional feature.
<head> [...] <link rel="z3986-version" href="http://purl.oclc.org/z3986/2010/auth/profiles/book/1.0/"> <link rel="z3986-feature" href="http://purl.oclc.org/z3986/2010/auth/features/mathematics/3.0/"/> <link rel="z3986-feature" href="http://purl.oclc.org/z3986/2010/auth/features/chemistry/1.1/"/> </link> [...] </head>
In each document instance, the version link must occur exactly once. The z3986-feature link cardinality is unbound (0-n). Note that both the Profile and the Feature URIs contain version information (the trailing segment).
The document instance conformance rules require a document instance to declare which Optional Features are used in the body of the document (using head/link as above). Likewise, an instance must not declare a Optional Feature that is not actually used. Violation of any of these two constraints is a validity breach.
Processing Agent Support and Conformance
Declaration of Support
Processing Agents declare support for Optional Features separately from Profiles.
Processing Termination Rules [TBD]
In the case of Authoring and Interchange, as opposed to Distribution, we employ a quite draconian approach to encounters of the unknown:
- If an instance document uses a Profile that a Processing Agent does not recognize, the Processing Agent must abort processing.
- If an instance document uses an Optional Feature that a Processing Agent does not recognize, the Processing Agent must abort processing.
- If an instance document uses a Profile version or an Optional Feature version that a Processing Agent does not recognize, the Processing Agent may abort processing. The loosening of the rule here is because Processing Agents may have support for RDF-based fallback behaviors, and a Profile may include support for inline content fallback (such as DISELECT using version switches).
Note also that some Features may be irrelevant to some Processing Agents. Example: a speech pronounciation Feature would be irrelevant to a Braille output processor, and would thus be ignored during processing - in the simplest case, any element in the namespace defined by the feature can simply be filtered out[2]. But the Braille processor is still required to recognize the Optional Feature (in order to know that it can safely ignore it).
Versioning
As can be seen in the Document instance identity declaration section above, Profile and Optional Feature identity and versions are declared independently of eachother. Through this, a Processing Agent is able to evaluate all these declarations independently in the instance document head, and make an informed decision on whether it can continue the processing.
The maintainer of a Profile is in charge of determining what changes in a Profiles components trigger a Profile version change.
The maintainer of an Optional Feature is in charge of determining what changes in an Optional Feature trigger a Optional Feature version change.
In general, the following can be said about version change triggering and the co-depencendies of Profiles and Optional Features:
- A change in a Profile Core Grammar triggers a change of the Profile version
- A change in an Optional Feature triggers a change in the Optional Feature version, but not in the Profile version, unless the host integration pattern is affected
Graph: Architecture Overview
The graph summarizes the building blocks of the ZedAI architecture. It should be consumed starting at the bottom.
Notes
[1] Note - "addon" role taxonomies are not contributed directly via features, primarily because they have different Processing Agent behaviors associated with them. An unrecognized role CURIE is not a reason to abort processing, wheras an unrecognized feature is.
[2] This may actually be a good reason to require Optional Features to have namespaces other than the two core XHTML2 and Z3986 namespaces.
