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

Re: Disjoint Unions was using otherprops

Expand Messages
  • Deborah Pickett
    ... This is where I sheepishly admit that there isn t an automatic solution for this, yet. This is what I do: The step that needs to be different on each
    Message 1 of 13 , Jul 1, 2007
    • 0 Attachment
      --- In dita-users@yahoogroups.com, "davidjbh" <david.hollis@...> wrote:
      > In the <steps> example below, it would be conceivable to have a
      > <step> per Platform, with the intention of including the right one
      > at process time.
      > So, how would you go about avoiding disjoint unions in a Platform
      > type scenario?

      This is where I sheepishly admit that there isn't an automatic
      solution for this, yet.

      This is what I do: The step that needs to be different on each
      platform, I don't put into the task itself. Instead I put an empty
      step with a conref:
      <step conref="../../byplatform/flossingcats.xml#topicid/stepid">
      <cmd/>
      </step>

      "byplatform" is, in our build environment, a symbolic link which I set
      at build time to point to one of several real directories, each with
      identical structure (in this case, all with a flossingcats.xml file).
      flossingcats.xml isn't a user-visible task; it's a skeleton task with
      enough scaffolding content to enable me to make a step, which I give
      the id "stepid".

      Of course, this works only on file systems that have a concept of a
      symbolic link, and only if you have set up infrastructure around a
      DITA-OT build system to change where byplatform points. I get these
      for free with my source code control system.

      I've glossed over several details here, but you get the idea. The
      important thing is that "byplatform" can point to only one directory
      at a time, so you get the disjoint-union behaviour, guaranteed.

      You can imagine that there's some overhead to doing this, not the
      least of which is that there are multiple files to manage.
      Fortunately for our documentation set the need to do this is
      infrequent. We mostly do it to insert product version numbers into
      text so that they can be automatically bumped when a new version comes
      out.

      A better solution will appear once the keyref attribute is completely
      specified and implemented in DITA-OT. This is one of the things that
      keyref is supposed to be able to solve, because it gives you that
      extra level of indirection.
    • davidjbh
      Hi, Deborah Thank you for explaining how your build process currently works, and how you handle the platform issue. Most enlightening! This is, presumably,
      Message 2 of 13 , Jul 3, 2007
      • 0 Attachment
        Hi, Deborah

        Thank you for explaining how your build process currently works, and
        how you handle the platform issue. Most enlightening!

        This is, presumably, because the Toolkit doesn't yet support
        action="include" for ditaval files?

        But this is, surely, about to change? With the next release of the
        Toolkit?

        When action="include" is supported by the Toolkit, how would you see
        this affecting the disjoint union scenario for platform filtering?

        Many thanks,
        David


        --- In dita-users@yahoogroups.com, "Deborah Pickett"
        <deborah_pickett@...> wrote:
        >
        > --- In dita-users@yahoogroups.com, "davidjbh" <david.hollis@>
        wrote:
        > > In the <steps> example below, it would be conceivable to have a
        > > <step> per Platform, with the intention of including the right
        one
        > > at process time.
        > > So, how would you go about avoiding disjoint unions in a
        Platform
        > > type scenario?
        >
        > This is where I sheepishly admit that there isn't an automatic
        > solution for this, yet.
        >
        > This is what I do: The step that needs to be different on each
        > platform, I don't put into the task itself. Instead I put an empty
        > step with a conref:
        > <step conref="../../byplatform/flossingcats.xml#topicid/stepid">
        > <cmd/>
        > </step>
        >
        > "byplatform" is, in our build environment, a symbolic link which I
        set
        > at build time to point to one of several real directories, each
        with
        > identical structure (in this case, all with a flossingcats.xml
        file).
        > flossingcats.xml isn't a user-visible task; it's a skeleton task
        with
        > enough scaffolding content to enable me to make a step, which I
        give
        > the id "stepid".
        >
        > Of course, this works only on file systems that have a concept of a
        > symbolic link, and only if you have set up infrastructure around a
        > DITA-OT build system to change where byplatform points. I get
        these
        > for free with my source code control system.
        >
        > I've glossed over several details here, but you get the idea. The
        > important thing is that "byplatform" can point to only one
        directory
        > at a time, so you get the disjoint-union behaviour, guaranteed.
        >
        > You can imagine that there's some overhead to doing this, not the
        > least of which is that there are multiple files to manage.
        > Fortunately for our documentation set the need to do this is
        > infrequent. We mostly do it to insert product version numbers into
        > text so that they can be automatically bumped when a new version
        comes
        > out.
        >
        > A better solution will appear once the keyref attribute is
        completely
        > specified and implemented in DITA-OT. This is one of the things
        that
        > keyref is supposed to be able to solve, because it gives you that
        > extra level of indirection.
        >
      • Deborah Pickett
        ... Probably it wouldn t make any difference. Conditional inclusion doesn t solve the arity problem (a can have only one ) any more than does
        Message 3 of 13 , Jul 3, 2007
        • 0 Attachment
          --- In dita-users@yahoogroups.com, "davidjbh" <david.hollis@...> wrote:
          > When action="include" is supported by the Toolkit, how would you see
          > this affecting the disjoint union scenario for platform filtering?

          Probably it wouldn't make any difference. Conditional inclusion doesn't solve the arity
          problem (a <task> can have only one <steps>) any more than does conditional exclusion.
          More importantly, there is still the risk of accidentally including content from more than one
          possibility (a <step> for product1 immediately followed by the corresponding <step> for
          product2). Worse, DITA-OT will happily do this without any error, because it isn't an error in
          the strict sense: there exist situations where product1 and product2 might be orthogonal
          rather than mutually exclusive.

          Using conref and symlinks (and presumably keyref when it becomes mainstream) has the
          benefit of failing at an early stage in the build if there is a missing file/element or if the
          symlink isn't pointing to the right place.
        Your message has been successfully submitted and would be delivered to recipients shortly.