dita — archive

[Christopher Nitchie]

I've finally started working on my stage 3 proposal for loosening specialization rules. Looking back at the stage 2 proposal, it's very light on technical detail, so I'm working through those now, and could use some input, especially from technically-oriented folks. There are three design goals to this proposal: 1. Allow an attribute domain to add @base specializations to specific elements instead of globally. For example, this would allow developers to add custom table rendering controls only to table-related elements. 2. Allow "domain-local" element declarations - elements declared in a domain but not "published" to their base elements' alternative lists. For example, this would enable developers to create <xref> specializations with required child elements that only apply within that specialized <xref> (the example in stage to was <legislationref> with a nested <legislationsectionref> element). This might be legal in DITA 1.3; the spec, so far as I can tell, is ambiguous. 3. Allow domain elements to be inserted into specific content models instead of globally. For example, adding <sectiondescription> as a specialization of <p> only allowed within <section> and <example>. My proposed solution for (1) - context-specific @base specializations: a. Every element declares a "{elementName}-base-attr" parameter entity (DTD) or pattern (relax-ng) that is empty by default. b. Attribute domains declaring context-specific @base specializations publish them via a "{domainName}-{targetElement}-attribute" parameter entity. <! ENTITY % customTableRendering-d-entry-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-row-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-tgroup-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-tbody-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-thead-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-table-attribute "table-shading CDATA #IMPLIED table-fg CDATA #IMPLIED"> <! ENTITY % customTableRendering-d-att "a(base shading) a(base table-fg)"> c. DTD Doctype shells are responsible for merging various attribute domains' context-specific contributions to their target elements via their {elementName}-base-attr parameter entities. Relax-ng integration happens automatically. (I haven't actually figured out the relax-ng code yet but I think this works.) <! ENTITY % entry-base-attr "%customTableRendering-d-entry-attribute;"> <! ENTITY % row-base-attr "%customTableRendering-d-row-attribute;"> <! ENTITY % tgroup-base-attr "%customTableRendering-d-tgroup-attribute;"> <! ENTITY % tbody-base-attr "%customTableRendering-d-tbody-attribute;"> <! ENTITY % thead-base-attr "%customTableRendering-d-thead-attribute;"> <! ENTITY % table-base-attr "%customTableRendering-d-table-attribute;"> My proposed solution for (2) is simple; explicitly allow it in the spec. No new grammar file structures are required. Goal (3) is trickier. I considered something similar to solution (1) - a parameter entity that can be "published to" by domains for every element - but that won't work for content models other than choice lists. So instead I'm considering something like the following: 1. Create an element domain that contains domain-local declarations of the elements you want to inject into specific contexts. 2. Create a "constraint" module - though it's not actually a constraint - that adds those elements to their target context(s). I'd love some feedback on all this, but especially item (3). Thanks, Chris