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: Re: [dita] Spec Issue: Addressing Nested Topics


Hi, Paul:

Apparently, I hadn't had enough coffee before taking up the keyboard. A corrective addendum:


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


Inactive hide details for Erik Hennum/Oakland/IBMErik Hennum/Oakland/IBM


          Erik Hennum/Oakland/IBM

          10/06/2005 06:49 AM


To

"Paul Prescod" <paul.prescod@blastradius.com>

cc

dita@lists.oasis-open.org

Subject

Re: [dita] Spec Issue: Addressing Nested TopicsErik Hennum
Hi, Paul:

The first bullet in the document you referenced lays out the rules for addressing topics:

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:

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



Inactive hide details for "Paul Prescod" <paul.prescod@blastradius.com>"Paul Prescod" <paul.prescod@blastradius.com>


          "Paul Prescod" <paul.prescod@blastradius.com>

          10/06/2005 04:40 AM


To

<dita@lists.oasis-open.org>

cc


Subject

[dita] "Fragments of DITA content"

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



Inactive hide details for "Paul Prescod" <paul.prescod@blastradius.com>"Paul Prescod" <paul.prescod@blastradius.com>


          "Paul Prescod" <paul.prescod@blastradius.com>

          10/06/2005 04:32 AM


To

<dita@lists.oasis-open.org>

cc


Subject

[dita] Spec Issue: Addressing Nested Topics

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


GIF image

GIF image



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