OASIS Darwin Information Typing Architecture (DITA) TC

Re: [dita] Spec Issue: Addressing Nested Topics

  • 1.  Re: [dita] Spec Issue: Addressing Nested Topics

    Posted 10-11-2005 01:21
     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


    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:
      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



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



    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" <<a href=paul.prescod@blastradius.com>">"Paul Prescod" <paul.prescod@blastradius.com>



    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]