This looks very good and comprehensive.
Given that, it would nice if it would handle attribute renaming too -
as you suggest it might.
And I think it might also be the most appropriate place to handle the
long-deferred project to allow adding implementation-specific metadata
attributes to arbitrary elements.
Such attributes could be considered renamings of contained data or
associated data-about elements whose name attribute has the same name
as the implementation-specific attribute's name.
This makes more sense to me than evolving a
specialization/generalization mechanism for such attributes, given that
data elements, like implementation-specific attributes, have no generic
Something to think about while waiting on the platform for the train to
Erik Hennum wrote:
Hi, Energetic TC:
With DITA 1.1 on the train, DITA 1.2 strolls out of the waiting room
and onto the platform. So, we may want to take a fresh look at what
should be a priority for DITA 1.2
In particular, namespacing has been a perennial issue for DITA as part
of both TC conversations and on the user group (http://tech.groups.yahoo.com/group/dita-users/message/4950).
A significant challenge is how to correlate a namespaced element with a
type on the class attribute and, in particular, how to handle
namespaced elements as part of generalization and respecialization of
We'd like to bring forward a proposal that DITA 1.2 introduce a general
method for element aliasing that has broad value and then treat
namespacing as a special case of element aliasing. Once a DITA
Specification 1.2 Requirements category exists, I'll add the proposal
there, but for the interim, here it is:
Formatted: (See attached file: IssueAliasNamespace.html)
Source: (See attached file: IssueAliasNamespace.dita)
Hoping that's interesting,
DITA Proposed Feature - aliasing and namespacing
DITA Proposed Feature - aliasing and
Allow an element name to be an alias (with or without a namespace)
for its type from the class attribute.
The problem: Element
names are part of the XML document. There can be good reasons to prefer
- An organization might prefer <dl>, <deflist>, or
as different, appropriate resolutions of the tradeoff between economy
- An organization might prefer to use names from existing
For instance, an organization that's familiar with DocBook would likely
<variablelist> to <dl>.
- Spanish users would prefer <ejemplo> to <example>.
In addition, DITA has well-known problems with respect to
namespacing . Element names must reside in a namespace for some
Namespaces are essential to avoid naming collisions between specialized
created by independent designers and to embed DITA topics as part of
documents. Some XML users (using both DITA and other markup languages
however, argue that namespace prefixes reduce the usability and should
optional (included only where necessary to avoid collisions). Also,
and respecialization have no provision for namespaces.
As a related
issue, for types in the DITA class attribute, the module qualifier
to avoid naming collisions because two designers could pick the same
name and element name. As another related issue, DITA specialization
be extended to foreign vocabularies if the foreign vocabulary already
a non-DITA class attribute.
The solution: Decouple the element
name from the type in the class attribute.
- The default element name is the same as the type name.
- The document type shell that integrates vocabulary modules can
a namespace to all elements belonging to a vocabulary or alias specific
to different element names (with or without a namespace).
- The aliases for one vocabulary module can be packaged as a
module for inclusion in many document types.
- Generalization and respecialization operations use the alias
- New, generic unaliasing and aliasing transforms convert between
and the default element name.
Because processes match the type in the class attribute,
aliases for element names doesn't affect most of the existing
DITA-aware tools already inspect the class attribute to determine the
type of the element. Tools that recognize DITA element names but not
class attributes can process the result of the unaliasing transform.
- Non-professional writers
- An organization wants their marketing writers to create
These writers benefit from additional clarity in the markup, so the
creates an alias module that renames <dl> to
to <Figure>, <fn> to <Footnote>, and so on. The
documents look more
formal, but the writers understand what the markup means.
- Localized market
- A vendor is targeting the Spanish market with their offering.
creates an alias module that renames <example> to <ejemplo>
and so on.
The Spanish writers can make sense of the markup and embrace the
- DocBook consistency
- An organization has both DocBook and DITA adopters so, to make
content more comprehensible to the DocBook users, creates an alias
that renames <p> to <para>, <li> to <listitem>,
<dl> to <variablelist>,
and so on. The aliasing and unaliasing transforms allow the same
to make sense to both the DITA and DocBook heads.
- SOAP payload
- An IT department want to transmit DITA topics containing
descriptions as well as data as part of a SOAP payload. The staff
alias modules that put the DITA elements into namespaces (with prefixes
topic, concept, and so on ) so the SOAP send and receive functions can
the DITA content.
- Parallel invention
- One designer creates a DITA domain for documenting XML
another designer creates a DITA domain for documenting programming
After successful internal adoption, each designer decides to make the
publicly available. Both domains contain <element> for the XML
array senses (and thus, in DITA 1.1, cannot be used in the same
A DITA adopter installs both plugins and creates alias modules that use
to disambiguate <xm:element> and <pr:element> but that
leave the other
elements from both domains in the null namespace to provide a unified
for more usable authoring.
Element aliasing requires
the following changes:
- Each vocabulary can have at most one default namespace for its
If a default element namespace is provided, the vocabulary must also
a default prefix for the default element namespace. If a default
isn't provided, the null namespace is the default.
- The canonical element name for a type consists of the element
for the vocabulary module and a local name that's the same as the type
- The design patterns for DTD and XSD change to add a new
An aliasing module establishes the aliases for one vocabulary module.
document type shell integrates aliasing modules by importing each
setting the architectural attributes.
- The defaulted architectural attributes on the topic or map
of a vocabulary module to an element namespace or of one or more types
element names. Two types cannot share an element name.
- Generalization and respecialization operations change to check
architectural attributes before emitting element names.
- The generic aliasing and unaliasing operations are added to the
Open issues: Whether there's a strong need to
aliasing at present and, if so, how to represent that.
While not required
for element aliasing, it might be appropriate to consider the closely
namespacing problems with respect to DITA types at the same time. One
- Each vocabulary module can have one namespace for its types.
backward compatibility, the vocabulary type namespace cannot be
it can be strongly encouraged, required for aliasing elements from the
module, and required in a future version.
- The full type identifier for a type consists of the vocabulary
plus the type name (either in http style or in Java style as Paul
- A DITA element can have class attribute in the DITA namespace
with a defaulted
value that declares the type identifiers.
- Both design and transform modules use the RDF / XSLT technique
of a local
entity to incorporate the vocabulary type namespace into the DITA
class attribute and into transform expressions that match the DITA
- New utilities (for instance, using regular expressions in Java
languages) convert XSLT transforms between existing contains(@class,'
') expressions and new contains(@dita:class,' &module.ns;type ')
- The older class attribute can be deprecated but publishers of
encouraged to support both formats during transition.
Largest cost is for coming up with
a backward-compatible extension to the existing DTD and XSD design
and implementing that change.
Other hits are modifying the generalization
and respecialization transforms and implementing aliasing and
Avoiding naming collisions, viability
for namespace-required environments while conserving usability where
and adapting to local culture while reserving specialization for
If successfully backward
compatible, no forced changes for adopters though small encouraged
for every specialization publisher to declare type and element