ZedAI When to use Elements
From zedwiki
This document discusses principles to help ZedAI hybrid document designers distinguish the use of the XHTML2 Role attribute from the use of XML elements.
The document is intended to help grammar designers make sound choices when building ZedAI modules and/or profiles.
Contents |
Fundamental Principles
- The W3C Role framework was not created to make the use of XML Elements (with crafted QNames) redundant. Element QNames are still the fundamental vehicle to use to associate XML elements with semantics (and consequently, behaviors).
- The use of Role as designed by the W3C is primarily intended to express a specialization of a given element in a particular transient context (typically, in an instance document context).
- Thus, we can interpret the original W3C design intent such that a) the element QName is a symbol for a static semantic that b) can be refined dynamically by annotating the given XML element with @role.
- In ZedAI, we do not want to reinterpret this general principle, thus in grammar design terms we consider XML element QNames as the static (fundamental) definition of semantics, and @role as a way of dynamically enhancing that semantic.
- We do recognize that our definition of "dynamic" includes not only transient (the instance document) contexts, but also adaption to specific domains. (The usage of Role would reoccour using predictable patterns in multiple instance documents.) Roles can refer to pre-existing taxonomies (daisy-vocab, xhtml-vocab, etc) but any party could create their own (bana-vocab... ) to cover the needs of a specific domain. Using role for domain adaption is a means to avoid ZedAI profiles becoming overly complex, while still including an extensible framework allowing the expression of very finely grained semantics, where that need exists. This is also a means of allowing profiles to withstand a certain amount of societal change gracefully.
- We intend to use RDF taxonomies to define and contextualize both static semantics (element QNames) and dynamic semantics (roles).
Grammar Design Recommendations
- Using modules to assemble hybrid document models that allow effective usage of the element model alone is considered good practice. (Read: The element model alone should be semantically exhaustive in 80/20 terms)
- Using @role to refine of the semantic of a given element QName is considered good practice
- Using @role to impose a semantic on a semantically neutral QName is considered bad practice, unless it is done to circumvent overly complicated solutions
- Using @role to redefine the semantic of a given element QName is considered bad practice (or even illegal...)
- Assembling overly complex XML element tree models, disregarding the role framework, is considered bad practice (Read: If you start covering cases in the 20 section of the 80/20 rule with element names, you should consider using role instead)
On staying close to the host grammar
An expected sentiment of ZedAI grammar designers is to stay faithful to the host grammar (XHTML2) and reuse constructs from that grammar to the maximum extent possible.
In the general case, this is good practice. But it is bad practice to overdo the assimilation urge and use for example <x2:div @role="daisy:prodnote" to achieve this aim. In this example, the grammar designer should craft an XML Element QName instead.
It is also bad practice to overdo the assimilation urge by skewing the semantics or intended use of a construct or module provided in the host grammar. For example, <x2:nl> is not a sound alternative to <book:toc>.
In contexts where it is desirable to minimize hybridness/compoundness in order for ZedAI documents to be maximally compatible with mainstream (XHTML2) processors, grammar designers should take note of the fact that there are other vehicles to use than to be initially restrictive in terms of new element QName crafting:
- We do use RDF taxonomies to establish inwards associations, for example, d:pagebreak is statically a subclass of x2:separator
- The profile framework rule set could mandate or recommend that each profile provide a profile-to-plain-vanilla-xhtml2 XSLT through the RDDL directory.
Draft Notes on Processing Agent Behavior (processing elements and roles)
- A ZedAI compliant Processing Agent that traverses an instance document should when adapting its behavior consider both the given element QName and the possible occurence of an @role CURIE on the given element.
- If a processing agent encounters an @role CURIE that it does not recognize it should or must
- a) resolve the CURIE to its home taxonomy and see if it finds an owl:Class/QName association it recognizes there, else
- b) apply the behavioral contract as dictated by the element QName alone.
- If a processing agent encounters an @role CURIE that contradicts the behavioral contract of the XML element QName on which the CURIE occurs, it must throw an error? Or must ignore the role and apply the behavioral contract as dictated by the element QName alone?
Use of Role versus use of RDFa
(What do we want to say here? Perhaps: Role is for enhancing element/structural semantics, RDFa is for annotating actual content? A clear-cut distinction would be nice, we might get the XHTML2 WG to clarify this in spec prose.)
