Re: [dita] Behavior for xref format="ditamap"

["Don Day (LbyW)" <donday@learningbywrote.com>]

In fact, the use cases I'm exploring do not involve the Build scenario (which is predicated on resolving resources into a particular view) but rather a Discovery scenario (in which resources might be topics or maps or collections of either retrieved by API request--a query). Youtube is an example of a service that depends on both search (lists of results) and playlists (which for all the world could be maps of topicrefs to description topics) to help you find or create a queue to watch. So while my xref example looks indeterminate from a Build perspective, the Discovery perspective might see it as a request to generate a new list of resources to browse (where scope="external" might be defined as opening that result set in a new window rather than in the current (scope="local") window). Whereas the Build end use application is a PDF or content for infocenters or Help viewers, the Discovery application might be a CMS front end, or a service like YouTube, iTunes, Getty Images or Archive.org.

Along these lines, I've been mulling the pending demise of @query and realizing that a URL with a query parameter or a web service request is general enough to do the job for most access methods. The mime/media type request is part of the technical package for enabling some of these Discovery-based use cases as well. I see some interesting work ahead for the DITA4Web SC.

Don R. Day

DITA and XML Consultant, Learning by Wrote
Co-Chair, OASIS DITA Technical Committee

"Where is the wisdom we have lost in knowledge?

Where is the knowledge we have lost in information?"

--T.S. Eliot

On 12/4/2011 8:41 AM, Eliot Kimber wrote:

On 12/3/11 8:30 PM, "Don Day (LbyW)" <donday@learningbywrote.com> wrote:

   I found in one of my transforms a template for handling the syntactically
valid case of <xref href="" format="ditamap"/>. Is the processing
expectation for this combo defined anywhere? The 1.2 spec (3.4.2.9) defines
the format="ditamap" semantic solely in terms of topicref context, not
covering the xref case. Therefore this instance seems to be indeterminate. A
working solution might point to a first topic in the subject map, but if a
working result is not expected, implementers just need to know that it is
indeterminate.
 

I think the behavior must depend on the value of @scope.

If @scope is local, the behavior is either indeterminate or the first
topicref descendant of the referenced map.

If @scope is peer or external, then I think it has to function as a
cross-reference to a separate publication (root map), whatever that means
(remembering that we're still trying to define the syntax and semantics for
cross-publication links and addresses in DITA 1.3).

Through DITA 1.2 DITA has no well-defined semantic for doing
cross-publication addressing--addressing a map with scope != local is the
closest we have, the but rendition and behavior implications are entirely
unstated as far as I know.

Cheers,

E.