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'm good with both option 2s (previous email and this email). Let's keep things as simple as possible. I have never had a use for synph outside of syntaxdiagram at tens of clients over the past 20 years or so. If anyone needs it, they can update their shells appropriately.


Gershon Joseph | Senior Information Architect | Precision Content 
Direct: +972 (54) 658-3887| Email: gershon@precisioncontent.com | www.precisioncontent.com <http://www.precisioncontent.com/>

Unlock the Knowledge in Your Enterpriseâ

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. Â2020, Precision Content Authoring Solutions Inc, Mississauga, Ontario, Canada

ïOn 25/08/2020, 1:49, "dita@lists.oasis-open.org on behalf of Robert Anderson" <dita@lists.oasis-open.org on behalf of robert.dan.anderson@oracle.com> wrote:

    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,

    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.


        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.


    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:

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