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

Re: extracting vals from ditamaps...

Expand Messages
  • wilkins.robert
    ... file referenced in a map to ... started by adding a topic ... dita-ot1.2. The topic file I ... type= task ... type= task ...
    Message 1 of 8 , May 1, 2006
    • 0 Attachment
      --- In dita-users@yahoogroups.com, "wilkins.robert"
      <wilkins.robert@...> wrote:
      >
      >
      > I've been trying to use a stylesheet to pass values from a topic
      file referenced in a map to
      > the Antennal House DITOtoFO stylesheet, and have had no luck. I
      started by adding a topic
      > file to sample map (sequence.ditamap) that comes with the
      dita-ot1.2. The topic file I
      > added contains the usual 'bookinfo' kind of info:
      >
      > //prolog/copyrholder
      > //vrm/@version
      > //vrm/@release)
      > //copyryear[1]/@year
      > //copyryear[2]/@year
      >
      > I changed the map to look like this:
      >
      > <map title="Eclipse content aggregated by a map">
      > <topicref href="bookinfo.xml" type="topic"></topicref>
      > <topicref href="tasks/changingtheoil.xml"
      type="task"></topicref>
      > <topicref href="tasks/organizing.xml" type="task"></topicref>
      > <topicref href="tasks/shovellingsnow.xml"
      type="task"></topicref>
      > <topicref href="tasks/spraypainting.xml"
      type="task"></topicref>
      > .
      > .
      > .
      > </map>
      >
      > If I read against the test file, I can retrieve these values pretty
      easily. If I try reading the file
      > from the map, I can't seem to get anything going. Here's the code I
      used to test against
      > the bookinfo.xml file:
      >
      > <xsl:template match="/">
      > <xsl:value-of select="//prodname"/>
      > <xsl:variable name="MyCompany"
      select="concat(//prolog/copyrholder,'Inc.')"/>
      > <xsl:variable name="version" select="concat(//vrm/@version,
      '.',//vrm/@release)"/
      > >
      > <xsl:variable name="copyrdates"
      select="concat('© ',//copyryear[1]/
      > @year,' – ',//copyryear[2]/@year)"/>
      > <xsl:variable name="tmblock" select="concat('Copyright
      ',$copyrdates,' ',
      > $MyCompany, //body)"/>
      > <xsl:value-of select="$version"/>
      > </xsl:template>
      >
      > That works, but when I try to reference the file in the map, with
      code that looks like this:
      >
      > <xsl:template match="//topicref[@href='bookinfo.xml']">
      >
      > I seem to get a match on the file, but an editor full of white
      space. I know that I'm missing
      > something, but I'm clueless...and my fixit code gets uglier and uglier.
      >
      > Any suggestions?
      >
      Never mind...I finally realized that you can't get fancy and try to
      learn xpath at the same time. The solution is pretty easy - the
      "cover-create" stylesheet includes an instruction that says:

      <xsl:value-of select="//title[1]"/>

      You can import various items from the first topic to different regions
      by choosing different nodes and attributes, like this:

      <xsl:variable name="sybase" select="//topic[1]/prolog/copyrholder"/>

      Here's a new question though - I want to store all of book's bookinfo
      in one file, but not include the file in the toc or topic collection.
      Is there a way to keep this file hidden? I think I saw a 'toc="no"
      attribute somewhere that would take care of the toc, but what about
      surpressing the topic?

      ------- bob wilkins -------
    • Deborah Pickett
      (I m glad you worked out your problem. The original message was so beautifully written that I wanted to reply to it even though I didn t know the answer
      Message 2 of 8 , May 1, 2006
      • 0 Attachment
        (I'm glad you worked out your problem. The original message was so
        beautifully written that I wanted to reply to it even though I didn't
        know the answer offhand.)

        --- In dita-users@yahoogroups.com, "wilkins.robert"
        <wilkins.robert@...> wrote:
        > Here's a new question though - I want to store all of book's bookinfo
        > in one file, but not include the file in the toc or topic collection.
        > Is there a way to keep this file hidden? I think I saw a 'toc="no"
        > attribute somewhere that would take care of the toc, but what about
        > surpressing the topic?

        There's toc="no" and print="no". The former is used to stop the
        topicref and any of its children from appearing the navigation (table
        of contents). The latter is used to stop the topic and any of its
        children from appearing in the body of booklike print output.
        Obviously these aren't always used for every transformation type
        (@print isn't used for HTML, for instance). You can use both together
        for stuff that belongs in the map but should never appear in any
        output, such as reltables.

        I don't know if this is exactly what you are looking for, since I
        don't know what you mean precisely by "topic collection". If it
        isn't, then you might be wishing for something that is included in the
        bookmap specialization.
      • wilkins.robert
        ... Oops, when I referred to topic collection, I meant the topics or topicrefs referenced in the map. I m basically trying to find an alternative to the
        Message 3 of 8 , May 2, 2006
        • 0 Attachment
          --- In dita-users@yahoogroups.com, "Deborah Pickett"
          <deborah_pickett@...> wrote:
          >
          > (I'm glad you worked out your problem. The original message was so
          > beautifully written that I wanted to reply to it even though I didn't
          > know the answer offhand.)
          >
          > --- In dita-users@yahoogroups.com, "wilkins.robert"
          > <wilkins.robert@> wrote:
          > > Here's a new question though - I want to store all of book's bookinfo
          > > in one file, but not include the file in the toc or topic collection.
          > > Is there a way to keep this file hidden? I think I saw a 'toc="no"
          > > attribute somewhere that would take care of the toc, but what about
          > > surpressing the topic?
          >
          > There's toc="no" and print="no". The former is used to stop the
          > topicref and any of its children from appearing the navigation (table
          > of contents). The latter is used to stop the topic and any of its
          > children from appearing in the body of booklike print output.
          > Obviously these aren't always used for every transformation type
          > (@print isn't used for HTML, for instance). You can use both together
          > for stuff that belongs in the map but should never appear in any
          > output, such as reltables.
          >
          > I don't know if this is exactly what you are looking for, since I
          > don't know what you mean precisely by "topic collection". If it
          > isn't, then you might be wishing for something that is included in the
          > bookmap specialization.
          >
          Oops, when I referred to topic collection, I meant the topics or
          topicrefs referenced in the map.

          I'm basically trying to find an alternative to the default dita xsl-fo
          stylesheets(dita2fo-shell.xsl, etc.), and the Antenna House
          stylesheets look promising...but, of course, there are the stylesheets
          and getting the stylesheets to do what you want them to do.
        • wilkins.robert
          ... bookinfo ... collection. ... Perhaps I spoke too soon...the print= no %topicref-att hides the bookinfo topic a little too well. Is there something I can
          Message 4 of 8 , May 2, 2006
          • 0 Attachment
            --- In dita-users@yahoogroups.com, "wilkins.robert"
            <wilkins.robert@...> wrote:
            >
            > --- In dita-users@yahoogroups.com, "Deborah Pickett"
            > <deborah_pickett@> wrote:
            > >
            > > (I'm glad you worked out your problem. The original message was so
            > > beautifully written that I wanted to reply to it even though I didn't
            > > know the answer offhand.)
            > >
            > > --- In dita-users@yahoogroups.com, "wilkins.robert"
            > > <wilkins.robert@> wrote:
            > > > Here's a new question though - I want to store all of book's
            bookinfo
            > > > in one file, but not include the file in the toc or topic
            collection.
            > > > Is there a way to keep this file hidden? I think I saw a 'toc="no"
            > > > attribute somewhere that would take care of the toc, but what about
            > > > surpressing the topic?
            > >
            > > There's toc="no" and print="no". The former is used to stop the
            > > topicref and any of its children from appearing the navigation (table
            > > of contents). The latter is used to stop the topic and any of its
            > > children from appearing in the body of booklike print output.
            > > Obviously these aren't always used for every transformation type
            > > (@print isn't used for HTML, for instance). You can use both together
            > > for stuff that belongs in the map but should never appear in any
            > > output, such as reltables.
            > >
            > > I don't know if this is exactly what you are looking for, since I
            > > don't know what you mean precisely by "topic collection". If it
            > > isn't, then you might be wishing for something that is included in the
            > > bookmap specialization.
            > >
            > Oops, when I referred to topic collection, I meant the topics or
            > topicrefs referenced in the map.
            >
            > I'm basically trying to find an alternative to the default dita xsl-fo
            > stylesheets(dita2fo-shell.xsl, etc.), and the Antenna House
            > stylesheets look promising...but, of course, there are the stylesheets
            > and getting the stylesheets to do what you want them to do.
            >
            Perhaps I spoke too soon...the print="no" %topicref-att hides the
            bookinfo topic a little too well. Is there something I can use to keep
            bookinfo out of the book, but still use the attributes?

            Basically, I'm trying to mimic the same kind of functionality that
            bookinfo plays in the bookmap demo.
          • Don R. Day
            ... Ah, I see what you are asking for. When processing a bookmap, the dita2fo_shell.xsl transform specifically deselects this special-purpose topic knowing
            Message 5 of 8 , May 2, 2006
            • 0 Attachment
              --- In dita-users@yahoogroups.com, "wilkins.robert"
              <wilkins.robert@...> wrote:
              > ...Is there something I can use to keep
              > bookinfo out of the book, but still use the attributes?
              >
              > Basically, I'm trying to mimic the same kind of functionality that
              > bookinfo plays in the bookmap demo.
              >
              Ah, I see what you are asking for. When processing a bookmap, the
              dita2fo_shell.xsl transform specifically deselects this
              special-purpose topic knowing that it is not part of the intended
              output. However, if you process a bookmap as if it were a standard
              ditamap, the default process has no way to know that this is not a
              content topic, and will include it in the output.

              If you are not invoking dita2fo_shell.xsl, all bets are off. This
              transform needs work that is already in queue for the next patch
              release, so keep it on your shortlist of things to use, if FOP or
              Antenna House are your preferred formatters. (Idiom's plugin works
              exclusively with the RenderX XEP formatter, so it would be your choice
              for XEP.)

              Did you mention that you are using the AntennaHouse transforms from
              that company's web site? Those transforms do not make proper (any!)
              use of the DITA Open Toolkit for preprocessing, and therefore their
              output for map-driven results (and even for topics that have
              resolvable content) is suitable only as a demo of particular AH
              special behaviors.

              The remedies for this shortcoming are either to properly enable the AH
              transforms for specialization as yet another vendor-specific transform
              in the Toolkit, or to simply apply the AH peculiarities to a
              personalization module of the existing transforms. This is a much
              shorter path, IMO, than trying to get the AH-posted transforms to work
              properly as conforming DITA outputs for serious work.
              --
              Don Day
            • robert Wilkins
              I was afraid of that... We re still evaluating fo processsos, so we re not tied into a particular vendor. I know that the AH stylesheets include some
              Message 6 of 8 , May 2, 2006
              • 0 Attachment
                I was afraid of that...

                We're still evaluating fo processsos, so we're not
                tied into a particular vendor. I know that the AH
                stylesheets include some propriety extensions, but it
                looked promising...especially with some ugly deadlines
                on the horizon.

                I know you have dita2-fo.xsl fixes in the queue. I'm
                curious though - will the next version include the
                kind of bookinfo functionality in a regular map? One
                of the real short comings I found with the AH
                stylesheet is the way they retrieved the book info
                from topcic[1]...keeping that kind of information
                independent from a topic whose poistion in the map
                hierarchy (which may change in a subsequent release),
                referencing all the bookinfo via bookinfo.xml makes
                bookinfo maintenance much easier. Did that last
                sentence even make sense?

                Having said all that, the other problem is the
                trademark block. Righteous ugly and tedious to
                maintain, but most companies require them. Right now,
                we're working in a Frame-based environment, and any
                changes to the trademarks requires a physical update
                to the master page that includes the lists of company
                trademarks. Ideally, I'd like to include an
                instruction that imports the trademark list from some
                server somewhere, and inserts those values from some
                server somewhere into bookinfo, or directly into the
                fo block reserved for the trademarks. A little
                elegant, perhaps, but, something that frees the
                writers from some required maintenance, and makes our
                masters happy. Another item always up-to-date.

                Another promising part of the AH stylesheets were the
                instructions that retrieve topic sections and nest
                them into the toc. Most of these are formatted using
                proprietary extensions, too, which is too bad, because
                this kind of nesting is the kind of nesting that
                writers expect to see when they generate a toc. Part
                of the pale faces I see in writer faces is the pallor
                I see when the results is when they don't see the
                results they expect to see in something like the toc.

                I've babbled on much too long... must come from
                feeling the obligation of filling a left-hand page in
                a world before minimalism. I'll tell my handlers that
                tomorrow is another day. No pun, for sure...too brain
                dead for something like that.

                ----- me -----



                --- "Don R. Day" <dond@...> wrote:

                > --- In dita-users@yahoogroups.com, "wilkins.robert"
                > <wilkins.robert@...> wrote:
                > > ...Is there something I can use to keep
                > > bookinfo out of the book, but still use the
                > attributes?
                > >
                > > Basically, I'm trying to mimic the same kind of
                > functionality that
                > > bookinfo plays in the bookmap demo.
                > >
                > Ah, I see what you are asking for. When processing a
                > bookmap, the
                > dita2fo_shell.xsl transform specifically deselects
                > this
                > special-purpose topic knowing that it is not part of
                > the intended
                > output. However, if you process a bookmap as if it
                > were a standard
                > ditamap, the default process has no way to know that
                > this is not a
                > content topic, and will include it in the output.
                >
                > If you are not invoking dita2fo_shell.xsl, all bets
                > are off. This
                > transform needs work that is already in queue for
                > the next patch
                > release, so keep it on your shortlist of things to
                > use, if FOP or
                > Antenna House are your preferred formatters.
                > (Idiom's plugin works
                > exclusively with the RenderX XEP formatter, so it
                > would be your choice
                > for XEP.)
                >
                > Did you mention that you are using the AntennaHouse
                > transforms from
                > that company's web site? Those transforms do not
                > make proper (any!)
                > use of the DITA Open Toolkit for preprocessing, and
                > therefore their
                > output for map-driven results (and even for topics
                > that have
                > resolvable content) is suitable only as a demo of
                > particular AH
                > special behaviors.
                >
                > The remedies for this shortcoming are either to
                > properly enable the AH
                > transforms for specialization as yet another
                > vendor-specific transform
                > in the Toolkit, or to simply apply the AH
                > peculiarities to a
                > personalization module of the existing transforms.
                > This is a much
                > shorter path, IMO, than trying to get the AH-posted
                > transforms to work
                > properly as conforming DITA outputs for serious
                > work.
                > --
                > Don Day
                >
                >
                >
                >
                >

                __________________________________________________
                Do You Yahoo!?
                Tired of spam? Yahoo! Mail has the best spam protection around
                http://mail.yahoo.com
              • Don Day
                ... Actually, a regular map has very little book-specific metadata. The bookmap demo specialization provides such metadata through specialized elements. In
                Message 7 of 8 , May 5, 2006
                • 0 Attachment
                  dita-users@yahoogroups.com wrote on 05/02/2006 07:49:28 PM:

                  > I know you have dita2-fo.xsl fixes in the queue. I'm
                  > curious though - will the next version include the
                  > kind of bookinfo functionality in a regular map?

                  Actually, a regular map has very little book-specific metadata. The
                  bookmap demo specialization provides such metadata through specialized
                  elements. In the demo bookmap and bkinfo DTDs, those definitions were
                  spread across several locations, making authoring and maintenance somewhat
                  haphazard. Also, the fact that some of those specializations were based on
                  topic content elements was simply the best that could be done at the time.
                  In the proposed OASIS DITA 1.1 updates, there will be new elements for
                  specializing that will enable ALL book-related metadata to be a proper
                  child of the bookmap itself, more like most conventional book structures.
                  To recap, ditamaps provide basic relational and organizational structures
                  in a generic way (as a proper archetype should), whereas bookmap is a
                  particular adaptation designed to drive book-like processing, and the
                  proposed DITA 1.1 model for metadata helps clean up this picture
                  considerably.

                  > One
                  > of the real short comings I found with the AH
                  > stylesheet is the way they retrieved the book info
                  > from topcic[1]...keeping that kind of information
                  > independent from a topic whose poistion in the map
                  > hierarchy (which may change in a subsequent release),
                  > referencing all the bookinfo via bookinfo.xml makes
                  > bookinfo maintenance much easier. Did that last
                  > sentence even make sense?

                  Sorry, it didn't quite make sense to me, but perhaps my previous reply
                  spoke to that concern. I gave up on the AH stylesheets long before I even
                  got to how they retrieve book info--if the preprocess is not there, it is
                  not a conforming DITA application, and is of interest only as a technology
                  demo for the AH extensions.

                  > Having said all that, the other problem is the
                  > trademark block. Righteous ugly and tedious to
                  > maintain, but most companies require them. Right now,
                  > we're working in a Frame-based environment, and any
                  > changes to the trademarks requires a physical update
                  > to the master page that includes the lists of company
                  > trademarks. Ideally, I'd like to include an
                  > instruction that imports the trademark list from some
                  > server somewhere, and inserts those values from some
                  > server somewhere into bookinfo, or directly into the
                  > fo block reserved for the trademarks. A little
                  > elegant, perhaps, but, something that frees the
                  > writers from some required maintenance, and makes our
                  > masters happy. Another item always up-to-date.

                  You might look into conrefing your trademarks from a common file where the
                  most current definitions reside. In IBM, a custom function within the
                  editor analyzes the text of a topic, does lookups from a separate sidefile
                  of trademarks, and applies trademark markup only to the first occurance of
                  any hits within each topic (definitely a "last-thing-before-build" sort of
                  checklist item). This workflow ensures up-to-date compliance with
                  trademark definitions and policies for use in the output, but it is not the
                  only way. Other companies probably have different approaches for
                  consistency across large data collections.

                  > Another promising part of the AH stylesheets were the
                  > instructions that retrieve topic sections and nest
                  > them into the toc. Most of these are formatted using
                  > proprietary extensions, too, which is too bad, because
                  > this kind of nesting is the kind of nesting that
                  > writers expect to see when they generate a toc. Part
                  > of the pale faces I see in writer faces is the pallor
                  > I see when the results is when they don't see the
                  > results they expect to see in something like the toc.

                  If the AH stylesheets do this, it is because of a critical misunderstanding
                  about sections vs hierarchy.

                  The hierarchy of a complex topic is expressed in either a ditamap (which
                  references topics, not sections), or though the actual nesting of child
                  topics within a parent, which achieves the same result. A ToC models that
                  hierarchy of required topic titles. Trying to infer the use of optional
                  section titles as hierarchy when there is already a hierarchy model is
                  futile, and also subject to different rules depending on the application
                  (lessee, do I want section titles when the topic is anything but a
                  reference or task?)

                  I picked on reference and task because in a command reference (a very
                  common use case, like Unix man pages), what use is it to see the headings
                  Syntax, Flags, Files (all section title equivalents in DITA) repeated ad
                  nauseum in a table of contents? For task, the same applies to
                  Prerequisites, Steps, Results, etc, appearing in a table of contents. While
                  printing these subheadings within the topic is reasonable (depending on
                  corporate style), few books ever reproduce these in a ToC--the repeated
                  monotony makes the ToC far less concise and usable. Even for concepts, the
                  nesting rule still applies for topic titles that go into a ToC. Sections
                  are defined only for direct support of the current discourse, and if the
                  *optional* section title is even used, it is basically as a highlight
                  point--you don't see "Note:" as part of a ToC collection, for example.

                  Writers need only expect that the required titles of topics (however the
                  hierarchy is expressed, by map or literal nesting) will go into a Table of
                  Contents. The optional titles of sections never go into a Table of
                  Contents, any more than the highlighted intros to notes or other blurbs
                  would.

                  Now, could you have an index of sections if you wished? YES! The new DITA
                  1.1 bookmap includes a booklist element that you can specialize to
                  represent a collection of things of a kind, such as a collection of code
                  examples or syntax diagrams (and then, usually only those that have
                  titles). So if you want to collect titled sections for whatever reason,
                  you can certainly create an override to do so. Its the specialized cases
                  that might be of more interest for readers to look up--here I imagine a
                  section specialized as a <bio> element, which would support building an
                  "About the authors" booklist of biographical blurbs scattered throughout a
                  map of conference proceedings).

                  > I've babbled on much too long... must come from
                  > feeling the obligation of filling a left-hand page in
                  > a world before minimalism. I'll tell my handlers that
                  > tomorrow is another day. No pun, for sure...too brain
                  > dead for something like that.

                  I hope these explanations help explain why the standard processing is in
                  fact a best implementation that has very good reasons behind the behaviors.
                  Life (and your own tooling support) is simple(r) if you build on it and on
                  the intended architectural principles of DITA.


                  Regards,
                  --
                  Don Day
                  Chair, OASIS DITA Technical Committee
                  IBM Lead DITA Architect
                  Email: dond@...
                  11501 Burnet Rd. MS9033E015, Austin TX 78758
                  Phone: +1 512-838-8550
                  T/L: 678-8550

                  "Where is the wisdom we have lost in knowledge?
                  Where is the knowledge we have lost in information?"
                  --T.S. Eliot
                Your message has been successfully submitted and would be delivered to recipients shortly.