dita — archive

[Robert Anderson]

Hi Jeff, I don't want to put words in Michael's mouth, I'll give my own take on this. The toolkit has several overrides for specializations, although I think that probably covers under a third of them. Offhand, I do not remember if any of these are done to meet definitions in the spec, although I would rather expect not. Also, I'd agree that the spec does not define a standard method to share processing behaviors - it just defines how the class attribute can and should be used to handle specialized processing. That said -- there are many cases where a user defining a specialized element reasonably expects to be able to get processing that does not match the default fallback. I've seen several cases where specializations are created in order to provide standard headers, text formatting or both. The DITA spec does not forbid this, and does not provide a way to share those modified behaviors among implementations. That is, there is no way for me to define a specialized table such that all processors know that the first column should have a (locale specific) default heading, although this is not an uncommon thing to want. I think that the proposal I originally submitted just goes much further than the rest of the spec in pointing out that users may want a behavior from their specialization that does not match the element from which they've specialized. My own feeling is that this is not something new - it has always been the case that a behavior might change due to specialization. I probably just gave more details about it because, at the time of writing, I had already seen several examples of that in practice. In terms of encoding the behaviors in the DTD or Schema - I do not think that the behaviors are simple enough to encode. A lot of the examples I've seen come from Erik Hennum, so perhaps he can provide use cases here, but an attribute that lists element names seems too simple. There is more than one possible behavior that can be overridden for a map reference, so a simple inherit/notinherit value probably won't cover many of the use cases. I'm going to rely on Erik to provide those more complex examples. To summarize, I think that it is normal for a specialized element to desire processing that differs from its ancestor. Perhaps the proposal 12055 as submitted went overboard in anticipating behaviors, and implying that processors had to be ready to deal with them. Would it be better to simply define the defaults, and state that as with any specialization, these behaviors may change, but that achieving such changes are up to implementation specific solutions? Thanks for the discussion - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 (Good Monday & Thursday) "Ogden, Jeff"