Re: [dita] Allowing Domains to Extend Specific Elements

[Chris Nitchie <chris.nitchie@oberontech.com>]

Eliot,

This looks like it overlaps considerably with my existing proposal to loosen attribute specialization rules (allow specializations of @base to apply only to specific elements). See

https://github.com/oasis-tcs/dita/issues/15

I hadn’t considered doing the same for content models, but I should have. I think it makes a lot of sense.

Chris

On 6/6/17, 12:11 PM, "dita@lists.oasis-open.org on behalf of Eliot Kimber" <dita@lists.oasis-open.org on behalf of ekimber@contrext.com> wrote:

    I think this can be defined as a refinement of the constraint mechanism, such that for DITA 2.0 we formally allow the integration of domains where the base global integration is *not* done and separate declarations are created that add the domain elements and/or attributes to specific elements. The constraint should still be declared because it is a constraint and it makes it clear that something other than the normal global integration is at work. 
    
    This is a constraint because you’re defining a rule that is more constrained then the base rule (global extension). This approach would simply make it syntactically convenient by allowing this kind of selective modification of content models and attributes. 
    
    Syntactically this requires overriding the content models or attribute list declarations of each element to which the domain applies, which is no different from any other constraint from an implementation standpoint. Note that per the DITA 1.3 rules, you can only do this type of selective extension in a conforming way by overriding the content models of all the element types you *don’t* want the domain to apply to. That’s clearly not reasonable, so this approach basically lets you do what the constraint mechanism should have always let you do.
    
    For DTDs this is done in separate constraint modules that occur before the base declarations (but because of the way DTDs work can lead to the need to do things like duplicate parameter entity declarations from the topic.mod or map.mod which otherwise will only occur after any constraint module could be included and therefore can’t be referenced from those modules). (And here  it might be appropriate to include in the proposal refactoring topic.mod and map.mod to move those entity declarations out to separate modules so that they can be used in constraint modules—the current DTD organization has always been problematic in that these two modules don’t follow the general rule for structural modules and cause problems as a result.)
    
    For RNGs you can override patterns directly in shells, which is analogous to overriding parameter entities in DTDs, or you can include a module that overrides patterns. The mechanism is conceptually the same as for DTDs: you simply override the complete pattern you’re extending—there’s no way to selectively extend the pattern of a specific element (but I could be wrong there—I’ll have to research). One difference in RNG is that modules not intended to be globally integrated would need to omit the normal global pattern extension that makes RNG modules self integrating (at least I think they would).
    
    Cheers,
    
    E.
    
    
    --
    Eliot Kimber
    http://contrext.com
     
    
    
    
    
    ---------------------------------------------------------------------
    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