Next in thread → Next in month →

Fwd: Re: [oasis-tcs/dita] What are the rules for nested conrefs within a conref push? (#346)

From
Kristen James Eberlein <>
Date
2020-02-05T15:43:23+00:00
ID
Thread
Fwd: Re: [oasis-tcs/dita] What are the rules for nested conrefs within a conref push? (#346)
FYI.

    

    
Best,

      Kris

      

      Kristen James Eberlein

      Chair, OASIS DITA Technical Committee

      Principal consultant, Eberlein Consulting

      www.eberleinconsulting.com

      +1 919 622-1501; kriseberlein (skype)

      

    

    

      

      -------- Forwarded Message --------
      
        
          

            Subject:
            
            Re: [oasis-tcs/dita] What are the rules for nested
              conrefs within a conref push? (#346)
          

          

            Date: 
            Wed, 05 Feb 2020 07:40:52 -0800
          

          

            From: 
            Robert D Anderson <>
          

          

            Reply-To:
            
            oasis-tcs/dita
<>
          

          

            To: 
            oasis-tcs/dita <>
          

          

            CC: 
            Subscribed <>
          

        
      
      

      

      
We discussed this as the OASIS TC on Tuesday, and the general
        thinking was along the lines of -- what's inside a block is
        resolved in the new context, the same way it would be for XREF.

      
As I write that up here though I'm not sure it's workable --
        that design works because XREF is pretty much always evaluated
        after conref or conref-push, because it's something that you can
        hold off almost until rendering time.

      
If conref and conref-push are evaluated separately (which they
        are today in DITA-OT, and maybe / probably in other tools), this
        doesn't work. Whichever is processed first is handled in that
        context, whether it is inside or outside.

      
I think I'll have to raise that issue with the TC again next
        week, and hopefully come back with a clearer answer. Whatever
        the answer, it seems clear we need to address it in the next
        specification update.

      
â

        You are receiving this because you are subscribed to this
        thread.

        Reply to this email directly, view it on GitHub, or unsubscribe.
Next in thread → Next in month →