Loading ...
Sorry, an error occurred while loading the content.

Using a keyref to reference an anchor point within a topic

Expand Messages
  • Michael Anthony Smith
    Hi all, I have been converting some DocBook documentation into DITA. One aspect of this documentation is a generated tool parameter definition document. Here,
    Message 1 of 10 , Jun 19, 2013
    Hi all,

    I have been converting some DocBook documentation into DITA. One aspect of this documentation is a generated tool parameter definition document. Here, each defined parameter is given an anchor point (XML id attribute) which is intended for being used for cross-referencing target.

    When converting this documentation to DITA I created a DITA map (see attached params-with-defaults.ditamap) that contains a keydef for each parameter, which points to its anchor point in the underpinning DITA topic (see attached params-with-defaults.dita). An example of the keydef's that I am generating is:

    <keydef keys="param-defn-output-format"
               href="params-with-defaults.dita#reference_gen_params/param-defn-output-format"/>

    When running the default PDF and XHTML output transformations from within the oXygen 14.2 editor, I get the expected results. But, a significant number of warnings - five for each parameter (see the warnings.txt attachment for an example of each type of warning), which essentially state that I should not use the keyref in this manner.

    Any suggestions on how to do this sort of parameter cross-referencing correctly would be appreciated (along with any criticism on the use of DITA elements).

    Thanks,
    Anthony.

  • Eliot Kimber
    Keys cannot point to non-topic elements within topics, only to topics. The ID of the specific element you want to get to must be specified as part of the key
    Message 2 of 10 , Jun 19, 2013
    • 0 Attachment
      Keys cannot point to non-topic elements within topics, only to topics.

      The ID of the specific element you want to get to must be specified as part
      of the key reference on the cross references themselves.

      So in your example, the key definition should be:

      <keydef keys="reference_gen_params"
      href="params-with-defaults.dita#reference_gen_params"
      />

      And the cross reference would then be:

      <xref keyref="reference_gen_params/param-defn-output-format"/>

      Validation of the map should fail because the target of the keyref in your
      original is not a valid resource for key binding, meaning it is not a map, a
      topic, or a non-DITA resource. Just the presence of a "/" in the fragment
      identifier is sufficient to indicate an invalid URL because you would never
      address a topic by anything other than a fragment ID that is the topic ID.

      Cheers,

      Eliot

      On 6/19/13 1:43 PM, "Michael Anthony Smith" <anthony.smith@...>
      wrote:

      > Hi all,
      >
      > I have been converting some DocBook documentation into DITA. One aspect of
      > this documentation is a generated tool parameter definition document. Here,
      > each defined parameter is given an anchor point (XML id attribute) which is
      > intended for being used for cross-referencing target.
      >
      > When converting this documentation to DITA I created a DITA map (see attached
      > params-with-defaults.ditamap) that contains a keydef for each parameter, which
      > points to its anchor point in the underpinning DITA topic (see attached
      > params-with-defaults.dita). An example of the keydef's that I am generating
      > is:
      >
      > <keydef keys="param-defn-output-format"
      >
      > href="params-with-defaults.dita#reference_gen_params/param-defn-output-format"
      > />
      >
      > When running the default PDF and XHTML output transformations from within the
      > oXygen 14.2 editor, I get the expected results. But, a significant number of
      > warnings - five for each parameter (see the warnings.txt attachment for an
      > example of each type of warning), which essentially state that I should not
      > use the keyref in this manner.
      >
      > Any suggestions on how to do this sort of parameter cross-referencing
      > correctly would be appreciated (along with any criticism on the use of DITA
      > elements).
      >
      > Thanks,
      > Anthony.
      >
    • Michael Anthony Smith
      Thanks Elliot. -- -- ------------------------------------------------------------------------- Michael Anthony Smith, DeltaXML Ltd Michael Anthony Smith,
      Message 3 of 10 , Jun 19, 2013
      • 0 Attachment
        Thanks Elliot.
        -- 
        -- -------------------------------------------------------------------------
        Michael Anthony Smith, DeltaXML Ltd "Michael Anthony Smith, DeltaXML Ltd "Experts in Information Change""
        T: +44 1684 869035   E: anthony.smith@...   http://www.deltaxml.com
        Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

        On 19 Jun 2013, at 13:35, Eliot Kimber <ekimber@...> wrote:

         
        Keys cannot point to non-topic elements within topics, only to topics.

        The ID of the specific element you want to get to must be specified as part
        of the key reference on the cross references themselves.

        So in your example, the key definition should be:

        <keydef keys="reference_gen_params"
        href="params-with-defaults.dita#reference_gen_params"
        />

        And the cross reference would then be:

        <xref keyref="reference_gen_params/param-defn-output-format"/>

        Validation of the map should fail because the target of the keyref in your
        original is not a valid resource for key binding, meaning it is not a map, a
        topic, or a non-DITA resource. Just the presence of a "/" in the fragment
        identifier is sufficient to indicate an invalid URL because you would never
        address a topic by anything other than a fragment ID that is the topic ID.

        Cheers,

        Eliot

        On 6/19/13 1:43 PM, "Michael Anthony Smith" <anthony.smith@...>
        wrote:

        > Hi all,
        >
        > I have been converting some DocBook documentation into DITA. One aspect of
        > this documentation is a generated tool parameter definition document. Here,
        > each defined parameter is given an anchor point (XML id attribute) which is
        > intended for being used for cross-referencing target.
        >
        > When converting this documentation to DITA I created a DITA map (see attached
        > params-with-defaults.ditamap) that contains a keydef for each parameter, which
        > points to its anchor point in the underpinning DITA topic (see attached
        > params-with-defaults.dita). An example of the keydef's that I am generating
        > is:
        >
        > <keydef keys="param-defn-output-format"
        >
        > href="params-with-defaults.dita#reference_gen_params/param-defn-output-format"
        > />
        >
        > When running the default PDF and XHTML output transformations from within the
        > oXygen 14.2 editor, I get the expected results. But, a significant number of
        > warnings - five for each parameter (see the warnings.txt attachment for an
        > example of each type of warning), which essentially state that I should not
        > use the keyref in this manner.
        >
        > Any suggestions on how to do this sort of parameter cross-referencing
        > correctly would be appreciated (along with any criticism on the use of DITA
        > elements).
        >
        > Thanks,
        > Anthony.
        >


      • Eliot Kimber
        Note that there was at one time a DITA 1.3 proposal for creating indirect pointers to elements within topics, but the TC decided, correctly I think, to
        Message 4 of 10 , Jun 19, 2013
        • 0 Attachment
          Note that there was at one time a DITA 1.3 proposal for creating indirect
          pointers to elements within topics, but the TC decided, correctly I think,
          to withdraw the proposal in the name of minimizing complexity (and I'm
          saying that as one of the original champions of the proposal).

          Any mechanism that would allow indirection to elements within topics would
          necessarily be complex to understand, author, and support in authoring tools
          and component content management systems.

          Cheers,

          E.

          On 6/19/13 3:15 PM, "Michael Anthony Smith" <anthony.smith@...>
          wrote:

          > Thanks Elliot.
        • Jeremy H. Griffith
          ... Interesting. Too bad it got shot down. ... No. When we checked the DITA2Go code for this, we saw that we never considered the possibility of an @href in
          Message 5 of 10 , Jun 20, 2013
          • 0 Attachment
            On Wed, 19 Jun 2013 15:27:17 +0200, Eliot Kimber <ekimber@...> wrote:

            >Note that there was at one time a DITA 1.3 proposal for creating indirect
            >pointers to elements within topics, but the TC decided, correctly I think,
            >to withdraw the proposal in the name of minimizing complexity (and I'm
            >saying that as one of the original champions of the proposal).

            Interesting. Too bad it got shot down.

            >Any mechanism that would allow indirection to elements within topics would
            >necessarily be complex to understand, author, and support in authoring tools
            >and component content management systems.

            No. When we checked the DITA2Go code for this, we saw
            that we never considered the possibility of an @href
            in a keydef having a fragment identifier. So DITA2Go,
            out of the box, would handle the OP's requirement as is;
            the whole keydef @href would be used to access the target.

            However, if the @keyref has a fragment identifier too,
            that would be appended to the keydef @href, which is
            fine if the keydef has no fragment identifier, but is
            wrong if it does have one. We've fixed that now to
            remove any fragment identifier from the keydef @href
            **iff** the @keyref has one too. So the updated DLL
            will still do what the OP wanted.

            That seems like a very simple solution, not complicated
            at all. It follows the logic that the more specific
            takes precedence over the more general. The keydef may
            be referenced from any number of element @keyrefs; it
            defines the general case. So if it identifies an
            element at the target URI, that fragment identifier
            should be used, unless the more specific @keyref has
            one too, in which case the @keyref one overrides.

            What's complicated about that? ;-)


            -- Jeremy H. Griffith <jeremy@...>
            DITA2Go site: http://www.dita2go.com/
          • Eliot Kimber
            I think you may have missed a subtle aspect of my point. A topicref, and thus a key, can only point to a topic, a map, or a non-DITA resource. For maps there
            Message 6 of 10 , Jun 20, 2013
            • 0 Attachment
              I think you may have missed a subtle aspect of my point.

              A topicref, and thus a key, can only point to a topic, a map, or a non-DITA
              resource.

              For maps there would never be a need for a fragment identifier because maps
              can only be root elements, so it's always sufficient to simply address the
              XML document that contains the map (by the rules of DITA addressing,
              addressing an XML document implicitly addresses the root element of that
              document, except for <dita> documents, when it addresses the first <topic>
              child of the root).

              For non-DITA resources, any fragment identifier will be specific to the
              addressing semantics of the resource and is outside of DITA's purview, so if
              there is one, it's a black box.

              For topics, you may need a fragment identifier that addresses a topic within
              the XML document that contains it. This fragment identifier must be the XML
              ID of the topic. The topic so addressed may be the root topic or may be a
              subordinate topic.

              So in the case of keys bound to topics, there may be a fragment identifier.

              But...

              That fragment identifier can *only* be a bare XML ID.

              That means it could never be a topic ID/element-id pair.

              That is, this is a-priori meaningful:

              <keydef keys="key-01"
              href="topics/topic-01.dita#subtopic-02"
              />

              But this must be wrong:

              <keydef keys="key-01"
              href="topics/topic-01.dita#subtopic-02/fig-01"
              />


              Any indirection mechanism that allowed you to address non-topic elements
              indirectly would have to be separate from keys, because topicrefs only
              address topics. So it would add significant complexity to the spec. Would it
              be too much complexity? The TC's analysis was that it would be. If the
              community disagrees, it needs to provide strong evidence that the lack of
              such a feature is a serious impediment to the productive use of DITA.
              Because I'm Mr. Addressing, I'd love to see such a feature all things being
              equal, but we have finite resources to both develop the spec and implement
              and apply it.

              One potential option would be the XIndirect facility I submitted to the W3C
              as a note many years ago. As far as I know nobody ever implemented it and I
              never put any effort into promoting it. But the note still exists:
              http://www.w3.org/TR/XIndirect/

              XIndirect operates at the level of URI resolution, so it would ostensibly be
              outside of the DITA-defined addressing semantics. If somebody implemented
              general support for it in URI resolvers. Which now that I think about it,
              probably wouldn't be that hard to do, at least in the Java world.

              For the most part, indirect addressing is only of interest in an authoring
              context, as it adds no value in a delivery context (usually).

              Because the W3C essentially only concerns itself with delivery standards,
              the XIndirect facility was not of interest to the bulk of the W3C community.
              However, as a the first fully-Web-based authoring standard, perhaps DITA
              represents a new demand for W3C-providing authoring-support facilities....

              Cheers,

              E.

              On 6/20/13 5:39 PM, "Jeremy H. Griffith" <jeremy@...> wrote:

              > On Wed, 19 Jun 2013 15:27:17 +0200, Eliot Kimber <ekimber@...> wrote:
              >
              >> Note that there was at one time a DITA 1.3 proposal for creating indirect
              >> pointers to elements within topics, but the TC decided, correctly I think,
              >> to withdraw the proposal in the name of minimizing complexity (and I'm
              >> saying that as one of the original champions of the proposal).
              >
              > Interesting. Too bad it got shot down.
              >
              >> Any mechanism that would allow indirection to elements within topics would
              >> necessarily be complex to understand, author, and support in authoring tools
              >> and component content management systems.
              >
              > No. When we checked the DITA2Go code for this, we saw
              > that we never considered the possibility of an @href
              > in a keydef having a fragment identifier. So DITA2Go,
              > out of the box, would handle the OP's requirement as is;
              > the whole keydef @href would be used to access the target.
              >
              > However, if the @keyref has a fragment identifier too,
              > that would be appended to the keydef @href, which is
              > fine if the keydef has no fragment identifier, but is
              > wrong if it does have one. We've fixed that now to
              > remove any fragment identifier from the keydef @href
              > **iff** the @keyref has one too. So the updated DLL
              > will still do what the OP wanted.
              >
              > That seems like a very simple solution, not complicated
              > at all. It follows the logic that the more specific
              > takes precedence over the more general. The keydef may
              > be referenced from any number of element @keyrefs; it
              > defines the general case. So if it identifies an
              > element at the target URI, that fragment identifier
              > should be used, unless the more specific @keyref has
              > one too, in which case the @keyref one overrides.
              >
              > What's complicated about that? ;-)
              >
              >
              > -- Jeremy H. Griffith <jeremy@...>
              > DITA2Go site: http://www.dita2go.com/
            • Jeremy H. Griffith
              On Thu, 20 Jun 2013 18:56:35 +0200, Eliot Kimber ... Perhaps. ;-) ... I think you may have hit on the key problem right there. It makes sense in userland
              Message 7 of 10 , Jun 20, 2013
              • 0 Attachment
                On Thu, 20 Jun 2013 18:56:35 +0200, Eliot Kimber
                > <ekimber@...> wrote:

                >I think you may have missed a subtle aspect of my point.

                Perhaps. ;-)

                >A topicref, and thus a key, can only point to a topic, a map, or a non-DITA
                >resource.

                I think you may have hit on the key <g> problem right there.
                It makes sense in userland for a topicref to point only to
                a topic, and not to elements within the topic.

                But that is not true of a keydef. It would be if @keyrefs
                could only appear in topicrefs, but that is not the case.
                Almost any element can have a @keyref. Obviously, in many
                of those cases, addressing an element makes complete sense.

                So, from the POV of users, a keydef that is being used by
                an element other than a topicref should allow addressing
                of elements, and not just by the contortion of having the
                fragment ID in the @keyref.

                And why is this "invalid"? Because keydef is specialized
                from topicref, which means it inherits topicref's limitations.
                (That's another whole discussion, constraint vs. relaxation,
                but I won't launch it here.) Given the user needs above,
                I consider this specialization base to be a design error,
                an artifact of how DITA has grown. If anything, topicref
                should be derived from keydef, not the other way around,
                as keydef has a much larger set of use cases. Or keydef
                could be a basic type like topicref.

                >For maps there would never be a need for a fragment identifier because maps
                >can only be root elements, so it's always sufficient to simply address the
                >XML document that contains the map (by the rules of DITA addressing,
                >addressing an XML document implicitly addresses the root element of that
                >document, except for <dita> documents, when it addresses the first <topic>
                >child of the root).

                Again, from the user POV, that's generally true, but not
                always. For example, you might want to address a topicref
                within a map that contains other topicrefs, treating it as
                a submap without the overheads of actually moving it to a
                separate document. You do have the workaround of making
                that move, but not if you aren't the owner of the map,
                which could easily be the case in large pubs groups.

                >For non-DITA resources, any fragment identifier will be specific to the
                >addressing semantics of the resource and is outside of DITA's purview, so if
                >there is one, it's a black box.

                So there's no problem there, as in using an RFC 5147
                <http://tools.ietf.org/html/rfc5147> identifier for a
                coderef element. Yet if I understand you correctly,
                you still can't put such a URI in the @href of a keydef.

                >For topics, you may need a fragment identifier that addresses a topic within
                >the XML document that contains it. This fragment identifier must be the XML
                >ID of the topic. The topic so addressed may be the root topic or may be a
                >subordinate topic.
                >
                >So in the case of keys bound to topics, there may be a fragment identifier.
                >
                >But...
                >
                >That fragment identifier can *only* be a bare XML ID.
                >
                >That means it could never be a topic ID/element-id pair.
                >
                >That is, this is a-priori meaningful:
                >
                ><keydef keys="key-01"
                > href="topics/topic-01.dita#subtopic-02"
                >/>

                Yes...

                >But this must be wrong:
                >
                ><keydef keys="key-01"
                > href="topics/topic-01.dita#subtopic-02/fig-01"
                >/>

                It's a self-inflicted wound, resulting from choosing
                the wrong specialization base for keydef. IMHO.
                The keydef above should be a perfectly sensible way
                of addressing, say, a definition for a term.

                >Any indirection mechanism that allowed you to address non-topic elements
                >indirectly would have to be separate from keys, because topicrefs only
                >address topics. So it would add significant complexity to the spec. Would it
                >be too much complexity? The TC's analysis was that it would be. If the
                >community disagrees, it needs to provide strong evidence that the lack of
                >such a feature is a serious impediment to the productive use of DITA.
                >Because I'm Mr. Addressing, I'd love to see such a feature all things being
                >equal, but we have finite resources to both develop the spec and implement
                >and apply it.

                It doesn't take infinite resources to make keydef a
                basic element, rather than a specialization of topicref.
                And that one simple change would fix this problem.

                >One potential option would be the XIndirect facility I submitted to the W3C
                >as a note many years ago. As far as I know nobody ever implemented it and I
                >never put any effort into promoting it. But the note still exists:
                >http://www.w3.org/TR/XIndirect/

                Interesting! Thanks for the pointer; I have it
                up in Firefox now, and will read it closely.

                >XIndirect operates at the level of URI resolution, so it would ostensibly be
                >outside of the DITA-defined addressing semantics. If somebody implemented
                >general support for it in URI resolvers. Which now that I think about it,
                >probably wouldn't be that hard to do, at least in the Java world.

                Or in the C++ world. ;-)

                >For the most part, indirect addressing is only of interest in an authoring
                >context, as it adds no value in a delivery context (usually).
                >
                >Because the W3C essentially only concerns itself with delivery standards,
                >the XIndirect facility was not of interest to the bulk of the W3C community.
                >However, as a the first fully-Web-based authoring standard, perhaps DITA
                >represents a new demand for W3C-providing authoring-support facilities....

                XLink and XPointer, as opposed to XPath, never
                got much traction either. During the MicroXML
                discussions, they were brought up, but did not
                gain any support there. People seemed to think
                they were DOA. ;-)

                Thanks for the thoughtful analysis!

                Med venlig hilsen

                -- Jeremy H. Griffith, Omni Systems Inc.
                <support@...> http://mif2go.com
              • Eliot Kimber
                The discussion of whether or not key definitions done with topicrefs is moot, since it s something that can t be changed in DITA 1.x. For addressing elements
                Message 8 of 10 , Jun 20, 2013
                • 0 Attachment
                  The discussion of whether or not key definitions done with topicrefs is
                  moot, since it's something that can't be changed in DITA 1.x.

                  For addressing elements in maps, a key can address topicrefs using a
                  fragment identifier that is the ID of the topicref--maps represent a flat ID
                  space, so again, a fragment identifier that is a single bare ID (of a
                  topicref) is a valid URL for use with a topicref element.

                  XLink and XPointer failed to get traction largely for the same reason as
                  XIndirect: they are fundamentally authoring-domain. If you look at DITA
                  reltables, they are functionally equivalent to XLink extended links, but
                  constructed using topicrefs and DITA-specific addressing schemes.

                  XPointer imposes a lot of overhead to achieve design completeness, where
                  most people just need simple fragment identifiers, which in most cases are
                  just IDs or simple application-specific syntaxes.

                  As a co-editor of the HyTime 2 standard, I'm sympathetic to the desire for
                  complete designs and mathematical correctness. As a founding member of the
                  XML Working Group, I am also painfully aware of the reality of the 80/20
                  rule and the degree to which the pragmatic often trumps the elegant.

                  Cheers,

                  E.

                  On 6/20/13 8:04 PM, "Jeremy H. Griffith" <jeremy@...> wrote:

                  > On Thu, 20 Jun 2013 18:56:35 +0200, Eliot Kimber
                  >> <ekimber@...> wrote:
                  >
                  >> I think you may have missed a subtle aspect of my point.
                  >
                  > Perhaps. ;-)
                  >
                  >> A topicref, and thus a key, can only point to a topic, a map, or a non-DITA
                  >> resource.
                  >
                  > I think you may have hit on the key <g> problem right there.
                  > It makes sense in userland for a topicref to point only to
                  > a topic, and not to elements within the topic.
                  >
                  > But that is not true of a keydef. It would be if @keyrefs
                  > could only appear in topicrefs, but that is not the case.
                  > Almost any element can have a @keyref. Obviously, in many
                  > of those cases, addressing an element makes complete sense.
                  >
                  > So, from the POV of users, a keydef that is being used by
                  > an element other than a topicref should allow addressing
                  > of elements, and not just by the contortion of having the
                  > fragment ID in the @keyref.
                  >
                  > And why is this "invalid"? Because keydef is specialized
                  > from topicref, which means it inherits topicref's limitations.
                  > (That's another whole discussion, constraint vs. relaxation,
                  > but I won't launch it here.) Given the user needs above,
                  > I consider this specialization base to be a design error,
                  > an artifact of how DITA has grown. If anything, topicref
                  > should be derived from keydef, not the other way around,
                  > as keydef has a much larger set of use cases. Or keydef
                  > could be a basic type like topicref.
                  >
                  >> For maps there would never be a need for a fragment identifier because maps
                  >> can only be root elements, so it's always sufficient to simply address the
                  >> XML document that contains the map (by the rules of DITA addressing,
                  >> addressing an XML document implicitly addresses the root element of that
                  >> document, except for <dita> documents, when it addresses the first <topic>
                  >> child of the root).
                  >
                  > Again, from the user POV, that's generally true, but not
                  > always. For example, you might want to address a topicref
                  > within a map that contains other topicrefs, treating it as
                  > a submap without the overheads of actually moving it to a
                  > separate document. You do have the workaround of making
                  > that move, but not if you aren't the owner of the map,
                  > which could easily be the case in large pubs groups.
                  >
                  >> For non-DITA resources, any fragment identifier will be specific to the
                  >> addressing semantics of the resource and is outside of DITA's purview, so if
                  >> there is one, it's a black box.
                  >
                  > So there's no problem there, as in using an RFC 5147
                  > <http://tools.ietf.org/html/rfc5147> identifier for a
                  > coderef element. Yet if I understand you correctly,
                  > you still can't put such a URI in the @href of a keydef.
                  >
                  >> For topics, you may need a fragment identifier that addresses a topic within
                  >> the XML document that contains it. This fragment identifier must be the XML
                  >> ID of the topic. The topic so addressed may be the root topic or may be a
                  >> subordinate topic.
                  >>
                  >> So in the case of keys bound to topics, there may be a fragment identifier.
                  >>
                  >> But...
                  >>
                  >> That fragment identifier can *only* be a bare XML ID.
                  >>
                  >> That means it could never be a topic ID/element-id pair.
                  >>
                  >> That is, this is a-priori meaningful:
                  >>
                  >> <keydef keys="key-01"
                  >> href="topics/topic-01.dita#subtopic-02"
                  >> />
                  >
                  > Yes...
                  >
                  >> But this must be wrong:
                  >>
                  >> <keydef keys="key-01"
                  >> href="topics/topic-01.dita#subtopic-02/fig-01"
                  >> />
                  >
                  > It's a self-inflicted wound, resulting from choosing
                  > the wrong specialization base for keydef. IMHO.
                  > The keydef above should be a perfectly sensible way
                  > of addressing, say, a definition for a term.
                  >
                  >> Any indirection mechanism that allowed you to address non-topic elements
                  >> indirectly would have to be separate from keys, because topicrefs only
                  >> address topics. So it would add significant complexity to the spec. Would it
                  >> be too much complexity? The TC's analysis was that it would be. If the
                  >> community disagrees, it needs to provide strong evidence that the lack of
                  >> such a feature is a serious impediment to the productive use of DITA.
                  >> Because I'm Mr. Addressing, I'd love to see such a feature all things being
                  >> equal, but we have finite resources to both develop the spec and implement
                  >> and apply it.
                  >
                  > It doesn't take infinite resources to make keydef a
                  > basic element, rather than a specialization of topicref.
                  > And that one simple change would fix this problem.
                  >
                  >> One potential option would be the XIndirect facility I submitted to the W3C
                  >> as a note many years ago. As far as I know nobody ever implemented it and I
                  >> never put any effort into promoting it. But the note still exists:
                  >> http://www.w3.org/TR/XIndirect/
                  >
                  > Interesting! Thanks for the pointer; I have it
                  > up in Firefox now, and will read it closely.
                  >
                  >> XIndirect operates at the level of URI resolution, so it would ostensibly be
                  >> outside of the DITA-defined addressing semantics. If somebody implemented
                  >> general support for it in URI resolvers. Which now that I think about it,
                  >> probably wouldn't be that hard to do, at least in the Java world.
                  >
                  > Or in the C++ world. ;-)
                  >
                  >> For the most part, indirect addressing is only of interest in an authoring
                  >> context, as it adds no value in a delivery context (usually).
                  >>
                  >> Because the W3C essentially only concerns itself with delivery standards,
                  >> the XIndirect facility was not of interest to the bulk of the W3C community.
                  >> However, as a the first fully-Web-based authoring standard, perhaps DITA
                  >> represents a new demand for W3C-providing authoring-support facilities....
                  >
                  > XLink and XPointer, as opposed to XPath, never
                  > got much traction either. During the MicroXML
                  > discussions, they were brought up, but did not
                  > gain any support there. People seemed to think
                  > they were DOA. ;-)
                  >
                  > Thanks for the thoughtful analysis!
                  >
                  > Med venlig hilsen
                  >
                  > -- Jeremy H. Griffith, Omni Systems Inc.
                  > <support@...> http://mif2go.com
                • Jeremy H. Griffith
                  ... Oh, really? Why? Normally the reason for that is back compatibility , which I totally agree with. But not in this case. Consider; the fix I m
                  Message 9 of 10 , Jun 20, 2013
                  • 0 Attachment
                    On Thu, 20 Jun 2013 23:30:49 +0200, Eliot Kimber <ekimber@...> wrote:

                    >The discussion of whether or not key definitions done with topicrefs is
                    >moot, since it's something that can't be changed in DITA 1.x.

                    Oh, really? Why? Normally the reason for that is "back compatibility",
                    which I totally agree with. But not in this case. Consider; the fix
                    I'm suggesting is just a change of @class to remove the map/topicref,
                    and make it map/keydef. The impact on back compatibility is that if
                    a processor didn't understand keydef, it couldn't generalize it to
                    topicref. But it shouldn't do that anyway; imagine all your keydefs
                    inserting their referenced docs into the map wherever the keydefs
                    happened to be. Not a pretty picture; in fact, another strong reason
                    for *not* having that derivation. The more I look at it, the worse
                    the design error becomes. If policy is not to fix mistakes until 2.0,
                    you may never get to 2.0. XML hasn't. <g>

                    >For addressing elements in maps, a key can address topicrefs using a
                    >fragment identifier that is the ID of the topicref--maps represent a flat ID
                    >space, so again, a fragment identifier that is a single bare ID (of a
                    >topicref) is a valid URL for use with a topicref element.

                    OK, that's what I thought, before your previous post said what
                    appeared to be the opposite:
                    >>For maps there would never be a need for a fragment identifier because maps
                    >>can only be root elements, so it's always sufficient to simply address the
                    >>XML document that contains the map...

                    And indeed, DITA2Go has always supported that usage.

                    >XLink and XPointer failed to get traction largely for the same reason as
                    >XIndirect: they are fundamentally authoring-domain. If you look at DITA
                    >reltables, they are functionally equivalent to XLink extended links, but
                    >constructed using topicrefs and DITA-specific addressing schemes.

                    That explains a lot... I look at reltables as little as I can. ;-)
                    There has to be a better way, like just putting a reference in the
                    topicref topicmeta for every topic it should show as related. That
                    would be more compact, too, as well as more obvious.

                    >XPointer imposes a lot of overhead to achieve design completeness, where
                    >most people just need simple fragment identifiers, which in most cases are
                    >just IDs or simple application-specific syntaxes.
                    >
                    >As a co-editor of the HyTime 2 standard, I'm sympathetic to the desire for
                    >complete designs and mathematical correctness. As a founding member of the
                    >XML Working Group, I am also painfully aware of the reality of the 80/20
                    >rule and the degree to which the pragmatic often trumps the elegant.

                    Yes. And now and then, we get to have elegance that is also pragmatic.
                    That's what I aim for personally; don't always manage it, of course.
                    But when it comes to a choice, I have to go with the users, not the
                    math. I've been a toolmaker for over 40 years now, and still judge
                    my own work by how helpful it is to those using it, nothing else...
                    I've lost count of how many elegant ideas I've had that made people
                    go "Huh?". ;-)

                    I don't think this horse is moving any more... ;-)

                    -- Jeremy H. Griffith, at Omni Systems Inc.
                    <jeremy@...> http://mif2go.com/
                  Your message has been successfully submitted and would be delivered to recipients shortly.