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>?
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+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:
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.
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
