OASIS Darwin Information Typing Architecture (DITA) TC

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

ekimber@innodata-isogen.com
www.innodata-isogen.com

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

mpriestl@ca.ibm.com

http://dita.xml.org/blog/25





"W. Eliot Kimber"
<ekimber@innodata-isogen.com> 
01/22/2007 05:25 PM




To
<dita@lists.oasis-open.org>


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


ekimber@innodata-isogen.com

www.innodata-isogen.com