Are you sure you're looking at the most
recent draft? I remember that to-do hung around for a while after the attribute
specialization was documented, but it should be gone from the latest draft.
The attribute specialization pattern
is documented in the latest draft. The inheritance ancestry of a new attribute
is documented in the domains attribute.
A couple of things I notice looking
at that section:
- there's a dangling "The"
I should remove
- the nesting is unnecessarily deep
- I'll collapse a level of nesting, which should also have the side effect
of making the attribute specialization section pop out a bit more (right
now the heading disappears in amongst the others)
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
http://dita.xml.org/blog/25
"W. Eliot Kimber"
<>
01/22/2007 05:25 PM
To
<>
cc
Subject
[dita] Attribute Specialization
I notice that in the latest draft of the ditaspec.pdf,
there is a to-do
under "Modularization in DTDs" to the effect of "add info
on attribute
specialization".
OK--so how do we do attribute specialization, in particular of the base
attribute (it's slightly clearer for the conditional attributes).
If I read the specialization spec correctly we are not allowed to add
additional attributes to element types but there is the "base"
attribute
which is intended to allow arbitrary specialization.
But what is the mechanism for actually declaring that an attribute is a
specialization of "base" and what would be the point of doing
so?
That is, it's not clear to me how specializing from base= would aid
interoperability since it's local meaning must be application specific
(and therefore not generally interoperable). It's also not clear whether
specializing base means simply constraining the allowed values of the
base attribute for a particular element type or if it means declaring a
new attribute name that is somehow mapped to "base".
In the absence of a mechanism for remapping attribute names, it seems to
me that it would be sufficient to simply say that any attribute whose
name is not defined in the base DITA specification is by definition an
extension attribute, but that the declaration of such attributes should
not be prohibited. [NOTE: I'm not suggesting we have an attribute
renaming mechanism--that would be prohibitively complicated--I'm just
observing that we don't have one (and probably can't ever have one as
long as it's a goal to support non-schema-aware, naive processing of
DITA instances).]
If we wanted to be even more strict we could require that any private
attributes be in a namespace other than the DITA-defined namespace(s).
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198
www.innodata-isogen.com
