Re: [dita] Splitting syntax diagram domain -- update to original plan

[Robert Anderson <robert.dan.anderson@oracle.com>]

I think I lean that way as well.

If that's the consensus, the next question will be how to define the relationship between these domains.

The <synph> element has a content model that explicitly allows for <codeph> (still in the programming domain) plus <delim> and the other diagram elements. It does not allow the base <ph> element, in order to avoid lots of unrelated elements cropping up in this highly specific element. I don't intend to change this model -- the goal here is just simplifying stuff under the covers, not changing content models -- so we have two different options:

1. The new syntax diagram domain just has a dependency on programming. Not a problem, and works just fine; if you put syntax into your shells, you must also put in programming. In DITA 1.x this would require a complex token for the @domains attribute which few (if anyone) would understand; that token is gone now in 2.0.
 2. The new syntax diagram domain is a *specialization* of programming. The overall dependency is the same. It just declares, in the class attributes, that "This domain builds on programming". The class attributes look a little more odd; for example, the class attribute for synph would be:
"+ topic/ph pr-d/ph  syntaxdiagram-d/synph "

I think both approaches are valid, I think most people will never notice or care, it's just an implementation decision that has to be made because of the content model of <synph>.

If we go with "synph and syntax diagram in one domain", and nobody has a preference about this technical issue, I'll flip a coin and pick option 2.

Thanks again,
Robert

ïOn 8/24/20, 4:03 PM, "Eliot Kimber" <ekimber@contrext.com> wrote:

    I think I lean toward option 2: If you need synph outside of syntax diagrams you can configure your shell appropriately, but it seems unlikely that you ever would, so an all-or-nothing solution seems appropriate.

    I can see having a document that sometimes use <synph> outside of <syntaxdiagram> (for example, to talk about parts of a larger diagram) but it seems unlikely you'd use <synph> without also using <syntaxdiagram> one place or another.

    Cheers,

    E.
    --
    Eliot Kimber
    https://urldefense.com/v3/__http://contrext.com__;!!GqivPVa7Brio!M7vPknvUWFuqbqRVsnnvj072njg3KSryr3Wl-VX-vNMfBcrUXhye0iSU76jt2nJ6aXS420M$ 


    ïOn 8/24/20, 3:27 PM, "Robert Anderson" <dita@lists.oasis-open.org on behalf of robert.dan.anderson@oracle.com> wrote:

        While working on the stage 3 proposal, I ran into a problem with the original plan.

        Original plan: move <syntaxdiagram> and all child elements into new domain.

        Problem encountered: the <synph> element. Itâs the only element that can appear outside of diagrams, but which allows the syntax elements like <delim>.

        There are two ways to resolve this:

        1. Programming domain keeps synph, delim, kwd, oper, sep, and var. We still end up moving 11 syntaxdiagram elements into a new domain. Not as clean a break as hoped, but still a nice reduction.
        2. We move synph and syntaxdiagram both into the new domain.


        Each of those options mean that the new âsyntax diagram domainâ has a dependency on the programming domain. You can use programming without syntax (as intended), but you canât use syntax without programming. Which seems â fine? I have a hard time imagining someone that needs syntax diagrams but none of the other programming elements. Because of that dependency, I think the technical implementation would declare syntax diagram as a specialization of the programming domain. In the end, thatâs a technical detail that remains invisible to anybody not working on processors for these elements.

        Any preference on the direction?  I think it mostly comes down to whether itâs common to use <synph> without using <syntaxdiagram>. If so, we should go with option 1.

        Thanks,
        Robert