OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-07-2009 12:19 
    Given a root map and a subordinate map in a subdirectory under the root map,
where the subordinate map contains a topicref that specifies @href to a
topic, e.g., in the sub map:


  • 2.  RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-09-2009 02:00 
    










    


    Isn't this just a specific
example of the same problem that comes up in many contexts with conref? 
For example using the same setup as in the original example, but with somewhat
more content:
    


    


      <topicref
id="tr-01" href="../topics/topic-01.dita" >
    


          <topicref
href="../topics/topic-01.dita" />
    


      </topicref>
    


    


    If tr-01 is conrefed, should
the two @href values reference to the same file or not?
    


    


    I assume that the presence or
absence of processing-role="resource-only" doesn't make any
difference here, but if I've missed something, please let me know.
    


    


    Unless I've misunderstood
something, I just don’t think that this is an issue that we can take on
at this late stage of the DITA 1.2 cycle.
    


    


    Note that if this were a key
definition (it isn't), then the answer would be clear because the draft DITA
1.2 specification says:
    


    A relative URI in an href
attribute on a key definition is resolved relative to the location of the key
definition rather than relative to the location of the key reference.
    


    


       -Jeff
    


    


    > 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [dita] Conref of topicref to topicref: are relative URIsrewritten?

    Posted 11-09-2009 13:54 
    On 11/8/09 7:59 PM, "Ogden, Jeff"


  • 4.  Re: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-09-2009 14:09 
    > Are there any vendors who implement @conref who *don't* do what the
Toolkit
> does? If so, then we have an interoperation problem. If not, then we can
> probably safely codify the Toolkit behavior by adding a specific
statement
> about @href.

The implementations I worked on early in DITA's life blindly copied the
href as-is, and when people started getting more adventurous with conref
across directory boundaries, it came up very quickly as a bug. To me, it
seemed obvious what the behavior *should* be - href is adjusted to remain
valid - but I can see Eliot's point that a strict reading of the spec would
copy href as-is with other attributes.

I'm happy clarifying the spec as Eliot wants to do, because I do think this
is the expected and reasonable behavior. In the years we've been adjusting
href during conref resolution, I don't think I've ever heard from any user
who was surprised by it. But, I'm willing to re-evaluate that opinion if
there are vendors or users today who have a reason to support the blind
copy.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit


  • 5.  RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-09-2009 14:59 
    










    


    Does the DITA OT adjust all of the href values within conrefed
content or just the href values on the referenced element?
    


    


    Does the DITA OT adjust referencing attribute values
beyond @href? An example would be @conref and there are others.
    


    


    Where does the following case fall in this discussion?
    


    


    File: t1.dita
    


    <topic  id="t1">
    


     ...
    


       <p id="p1">Para1 in t1</p>
    


       <p id="p2">
    


          <xref
href="#t1/p1" />
    


     ...</p>
    


    </topic>
    


    


    File: t2.dita
    


    <topic  id="t2">
    


     ...
    


        <p id="p1">Para1 in
t2</p>
    


        <p conref="t1.dita#t1/p2"
/>
    


     ...
    


    </topic>
    


    


    When topic t2 is processed:
    


    1.  is
the xref in error because the id "t1" doesn't exist in topic t2?
    


    2.  or
is the xref a link to p1 in t1?
    


    3.  or
should the href value be rewritten to give a link to p1 in t2?
    


    


    All I'm saying is that there are a number of cases to
consider once you start down the road of adjusting things and I worry about approaching
this piecemeal for DITA 1.2 in a rush at the last minute without a formal
proposal and with only a short time for discussion (unless we slip the DITA 1.2
deadlines further and perhaps that is what we should do given all of the
questions that have been raised recently).
    


    


       -Jeff
    


    


    


    > 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-09-2009 15:09 
    






    The normative/non-normative 
strategy I heard articulated at some point was to state the desired outcome and 
leave it to the implementor to figure out how to get there.
    

     
    

    If we followed that strategy, 
then the way the OT handles @href could be given as an example. This seems to me 
a way of having our non-normative cake and eating it too in the form of examples 
of the implementation strategy that the OT uses.
    

     
    

    Re treatment of further 
references from within the referenced content:
    

      
  
    • 
  
      What is the desired 
  outcome?
      • 
  
    • 
  
      How does the OT deal with that 
  now, and could that be cited as an example for reaching the desired 
  outcome?
    

    
  
    /Bruce

    

    
  
    
  
    
  From: Ogden, Jeff [mailto:jogden@ptc.com]
    Sent: Monday, November 09, 2009 9:57 AM
    To: 
  dita
    Subject: RE: [dita] Conref of topicref to topicref: are 
  relative URIs rewritten?

    
  
    
  
    
  
    Does the DITA OT adjust all of the href values within 
  conrefed content or just the href values on the referenced 
  element?
    
  
    
  
    Does the DITA OT adjust referencing attribute values 
  beyond @href? An example would be @conref and there are others.
    
  
    
  
    Where does the following case fall in this 
  discussion?
    
  
    
  
    File: t1.dita
    
  
    <topic  id="t1">
    
  
     ...
    
  
       <p id="p1">Para1 in 
  t1</p>
    
  
       <p id="p2">
    
  
          <xref href="#t1/p1" 
  />
    
  
     ...</p>
    
  
    </topic>
    
  
    
  
    File: t2.dita
    
  
    <topic  id="t2">
    
  
     ...
    
  
        <p id="p1">Para1 in 
  t2</p>
    
  
        <p 
  conref="t1.dita#t1/p2" />
    
  
     ...
    
  
    </topic>
    
  
    
  
    When topic t2 is processed:
    
  
    1.  
  is the xref in error because the id "t1" doesn't exist 
  in topic t2?
    
  
    2.  
  or is the xref a link to p1 in t1?
    
  
    3.  
  or should the href value be rewritten to give a link 
  to p1 in t2?
    
  
    
  
    All I'm saying is that there are a number of cases to 
  consider once you start down the road of adjusting things and I worry about 
  approaching this piecemeal for DITA 1.2 in a rush at the last minute without a 
  formal proposal and with only a short time for discussion (unless we slip the 
  DITA 1.2 deadlines further and perhaps that is what we should do given all of 
  the questions that have been raised recently).
    
  
    
  
       -Jeff
    
  
    
  
    
  
    > 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 7.  Re: [dita] Conref of topicref to topicref: are relative URIsrewritten?

    Posted 11-09-2009 15:11 
    On 11/9/09 8:57 AM, "Ogden, Jeff"


  • 8.  RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-09-2009 15:16 
    Good point, I'd forgotten about that case. I think that came up several
months ago, and we decided it was too late in DITA 1.2 to try and resolve
that specific issue, given that implementations likely resolve it
differently today. I know what we do for that particular case, but (as
others often point out) what the OT does is not particularly relevant in
determining what the spec should do.

I'm not sure how that affects the more general case though, in that the (to
me) obvious behavior seems to be technically invalid. Perhaps some wiggle
room around the href attribute, stating that attributes containing relative
URIs may be adjusted as conref is resolved?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit


                                                                           
             "Ogden, Jeff"


  • 9.  Re: [dita] Conref of topicref to topicref: are relative URIsrewritten?

    Posted 11-09-2009 15:27 
    On 11/9/09 9:15 AM, "Robert D Anderson"


  • 10.  RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

    Posted 11-10-2009 06:30 
    










    


    Eliot asked:
    


    > Are there any vendors who implement @conref who
*don't* do what the Toolkit does?
    


    


    Arbortext Editor probably gets the same result as the
Toolkit, but not in the same way. Arbortext Editor uses a path list to resolve
relative references.  For DITA linking elements (conref, xref, link,
topicref, …) it is the ditapath list.  For graphic referendes
(image) it is the graphicspath list. The list usually consists of:
    


    


    1.  the
base URI for the referencing element (for conrefed elements this is the
directory for the document that contains the referenced element)
    


    2.  the
document directory for the referencing element, if this is different from the
base URI
    


    3.  zero
or more additional paths to directories
    


    


    We look for the referenced file starting with the first
location on the list and work our way down the list until we find the file or
we run out of locations to check.
    


    


    Users can change what is on the list or the order of the
paths on the list.
    


    


    So in Eliot’s example, we’d get the same
result as the OT, if the file exists at that location. If the file doesn’t
exist at that location, we might be able to continue if the file exists at one
of several other locations. Otherwise we report an error.
    


    


    This approach avoids the issue that Eliot raised without
having to “rewrite URIs”.  It works for a relative href on the
referenced element and for relative href values on markup within the referenced
element.
    


    


       -Jeff
    


    


    > 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content