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

Like Eliot, I prefer option #2.

That said, I have seen <synph> used in documentation where <syntaxdiagram> was not used. Most of the time it was in documentation for a division/group sold by IBM.

Do we want to ping dita-users about whether people are using <synph> without <syntaxdiagram>?


Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
+1 919 622-1501; kriseberlein (skype)

On 8/24/2020 4:27 PM, Robert Anderson 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]