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:
Apparently, I hadn't had enough coffee before taking up the keyboard. A corrective addendum:
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.)
Some of the architectural attributes are only available on the outer element for the content object. In particular, only <topic> and <map> have the domains attribute. Which means that conref validation (at least, coarse validation) has to have the outer element to verify that the domains used in the referenced content are also available in the destination. If they aren't, the referenced content fragment might contain an element that's invalid in the destination.
Apologies for the misinform,
Erik Hennum
ehennum@us.ibm.com

Erik Hennum/Oakland/IBM
Erik Hennum/Oakland/IBM
10/06/2005 06:49 AM
|
|
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]