OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


Eliot Kimber

ï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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]