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: Fwd: [oasis-tcs/dita] Is the "Example: Key definition with key reference" page correct? (#348)


More feedback coming in through GitHub ...

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)



-------- Forwarded Message --------
Subject: [oasis-tcs/dita] Is the "Example: Key definition with key reference" page correct? (#348)
Date: Tue, 18 Feb 2020 06:07:03 -0800
From: ChrisTrenkamp <notifications@github.com>
Reply-To: oasis-tcs/dita <reply+AAOG3BWVOZBRFZUKIYUDSWV4LERAPEVBNHHCDSTVDI@reply.github.com>
To: oasis-tcs/dita <dita@noreply.github.com>
CC: Subscribed <subscribed@noreply.github.com>


http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part3-all-inclusive/archSpec/base/example-keydef-with-keyref.html

In this example, the key reference to widget resolves to widgetInfo.dita. This took me by surprise because its behavior is inconsistent with the way linking generally works everywhere else in the specification. I would expect it to resolve to http://example.com/productPage.

http://docs.oasis-open.org/dita/dita/v1.3/os/part3-all-inclusive/archSpec/base/processing-key-references-general.html

The spec says that if both the keyref and href is present, the href must be used as a fallback when the keyname is unresolved.

http://docs.oasis-open.org/dita/dita/v1.3/errata02/os/complete/part3-all-inclusive/archSpec/base/conref-attributes-specified-on-elements.html

In addition to the fallback behavior, nested conref's have to be recursively resolved. I would expect key definitions to have the same recursive behavior, but the widget example does not have the same recursive behavior.

I then tested this in DITA-OT:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map>
  <topicref keyref="widget"/>
  <topicref keys="widget" href="http://test1" keyref="mainProduct" scope="external">
    <topicmeta><navtitle>Information about Widget</navtitle></topicmeta>
  </topicref>
  <topicref keys="mainProduct" href="http://test2" scope="external">
  </topicref>
</map>
<!DOCTYPE html
  SYSTEM "about:legacy-compat">
<html lang="en">
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta charset="UTF-8">
      <meta name="copyright" content="(C) Copyright 2020">
      <meta name="DC.rights.owner" content="(C) Copyright 2020">
      <meta name="DC.type" content="map">
      <meta name="DC.format" content="HTML5">
      <link rel="stylesheet" type="text/css" href="commonltr.css">
      <title></title>
   </head>
   <body>
      <nav xmlns:dita="http://dita-ot.sourceforge.net">
         <ul class="map">
            <li class="topicref"><a href="http://test2" target="_blank">Information about Widget</a></li>
            <li class="topicref"><a href="http://test2" target="_blank">Information about Widget</a></li>
            <li class="topicref"><a href="http://test2" target="_blank">http://test2</a></li>
         </ul>
      </nav>
   </body>
</html>

Even DITA-OT agrees that the widget example is inconsistent. Even tags like <xref keyref="widget"/> resolve to http://test2.

Is the widget example correct?

â
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.



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