OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]