MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Spec Issue: Addressing Nested Topics
Hi, Paul:
The first bullet in the document you referenced lays out the rules for addressing topics:
The complete identifier for a topic consists of the combination of the URI for the document instance, a separating hash character, and the topic id (as in http://some.org/some/directory/topicfile.xml#topicid).... As is typical with URIs, a relative URI can be used as the identifier for the document instance so long as it is resolvable in the referencing context. For instance, within a file system directory, the filename of the document instance suffices (as in some/directory/topicfile.xml#topicid). Within the same document, the topic id alone suffices (as in #topicid).
So, in DITA 1.0, topics cannot be addressed relative to another topic.
In passing, use, "topic content" should be defined and probably isn't quite the right term. What we need is a term that indicates everything contained by a topic except nested topics.
Because topicgroups and topicheads specialize topicref, the id definition for topicref (unique within document) applies to topicgroup and topichead as well:
For a map, the id of a map, topicref, or anchor must be unique within the document instance.
As for why a content fragment has to be addressed within a topic, my interpretation is that the rule ensures that processing and management always works with a consistent definition of a content object, even when sharing pieces of such objects. (Rather like using a class as the unit of definition and reuse in an object-oriented programming language instead of allowing reuse of functions outside of any class.)
Hoping that's useful,
Erik Hennum
ehennum@us.ibm.com
paul.prescod@blastradius.com>">"Paul Prescod" <
paul.prescod@blastradius.com>
http://docs.oasis-open.org/dita/v1.0/archspec/conref.html
“The target of a conref must be in a valid DITA topic or DITA map. Fragments of DITA content do not contain enough information on their own to allow the conref processor to determine the validity of a reference to them.”
What is the basis for this statement? Could some describe how the first of these documents contains more conref-processor-relevant information than the second?
1.
<?xml version="1.0"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<!-- Created with XMetaL 4.6 (http://www.xmetal.com) -->
<topic id="topic_5"><title>Title</title>
<body>
<p id="reusable">This is a reuable paragraph.</p></body></topic>
2.
<?xml version="1.0"?>
<!DOCTYPE p PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<!-- Created with XMetaL 4.6 (http://www.xmetal.com) -->
<p id="reusable">This is a reuable paragraph.</p>
Perhaps the spec could be clearer if it were explicit about what information the latter lacks.
As a best practice I actually prefer the former. The title element makes it easier to find the fragment. But a rationale based upon information management best practice is different than one based upon the needs of a conref processor.
Paul Prescod
paul.prescod@blastradius.com>">"Paul Prescod" <
paul.prescod@blastradius.com>
The DITA specification defines an addressing scheme for topics and another for “topic content”.[1] Topic content is not defined. Presumably it just means “sub-elements of topics”. Topics can be sub-elements of other topics. In this case, is either addressing scheme appropriate?
http://docs.oasis-open.org/dita/v1.0/archspec/id.html
While I am asking questions about this section: it seems not to deal with ID attributes on topicheads and topicgroups. There may be other unaddressed elements.
Paul Prescod
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]