Re: [dita] Feedback request: design for loosening specialization rules

[Eliot Kimber <ekimber@contrext.com>]

For (1), why is it limited to @base? Shouldn't the same thing be provided for @props? I certainly often have the requirement to have @props specializations that are only meaningful on specific element types.

I need to think about (1) more deeply but to date I've addressed this requirement by using "constraint" modules that provide attribute list declarations for the elements to which the attribute specializations should be allowed. Because you can have any number of attribute list declarations for single element, the use of parameter entities in this case doesn't seem to be necessary or add any value.

Your item (2) has always been allowed: domain elements may have whatever content model they want, including only allowing other specializations, as long as the resulting content model is consistent with the base content model. So I don't think the spec rules need to change, although the language could probably be clearer if the current language does not make this ability clear.

For (3) the main challenge has been that the base entity files were directly including in topic.mod, which made it impossible to selectively override content models of base elements using constraint modules (because constraints need to be able to refer to parameter entities after the parameter entities are declared but the base content model entities aren't (or weren't) declared until  topic.mod). I think we decided to correct that by moving the base entity declarations to separate modules that are included where they should be.

With that change it should be possible to have a constraint module that overrides the .content parameter entity of any element type without having to duplicate all the parameter entities referenced (directly or indirectly) from that content model (which is what you have to do today).

I would argue that the constraint mechanism always intended to allow this but we just didn't realize at the time how hard it would be to implement in DTD syntax.

Overriding a specific content model is, I think, the constraint equivalent of disallowing specific elements from a domain by omitting them from the domain integration parameter entity in a DTD (for example, only allowing "b" and "I" from highlight domain by listing them explicitly in the declaration of %ph rather than using %hl-d-ph).

Cheers,

E.

--
Eliot Kimber
http://contrext.com
 

ïOn 5/26/20, 8:53 AM, "Chris Nitchie" <dita@lists.oasis-open.org on behalf of cnitchie@gmail.com> wrote:

    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
    
    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that 
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php