Feedback request: design for loosening specialization rules

[Chris Nitchie <cnitchie@gmail.com>]

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