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

On xInclude

Expand Messages
  • Dave Pawson
    http://norman.walsh.name//2012/04/21/textFragid One aspect of it. I think this would be useful in DITA for the reasons given in the article. regards -- Dave
    Message 1 of 5 , Apr 22 12:02 AM
    View Source
    • 0 Attachment
      http://norman.walsh.name//2012/04/21/textFragid

      One aspect of it. I think this would be useful in DITA for the reasons given
      in the article.

      regards

      --
      Dave Pawson
      XSLT XSL-FO FAQ.
      Docbook FAQ.
      http://www.dpawson.co.uk
    • juliov27612
      Hi Dave, Wouldn t it make more sense to implement some method of identifying the desired content on the existing coderef element? Julio J. Vazquez SDI Global
      Message 2 of 5 , Apr 22 9:17 AM
      View Source
      • 0 Attachment
        Hi Dave,

        Wouldn't it make more sense to implement some method of identifying the desired content on the existing coderef element?

        Julio J. Vazquez
        SDI Global Solutions

        --- In dita-users@yahoogroups.com, Dave Pawson <dave.pawson@...> wrote:
        >
        > http://norman.walsh.name//2012/04/21/textFragid
        >
        > One aspect of it. I think this would be useful in DITA for the reasons given
        > in the article.
        >
        > regards
        >
        > --
        > Dave Pawson
        > XSLT XSL-FO FAQ.
        > Docbook FAQ.
        > http://www.dpawson.co.uk
        >
      • dave.pawson
        I find this approach works well, for XML or (now) plain text. http://dpawson.co.uk xslt xsl-fo docbook FAQ
        Message 3 of 5 , Apr 22 10:11 AM
        View Source
        • 0 Attachment
          I find this approach works well, for XML or (now) plain text.

          http://dpawson.co.uk
          xslt xsl-fo docbook FAQ


          On 22 Apr 2012, at 17:17, juliov27612 <julio_v27612@...> wrote:

          > Hi Dave,
          >
          > Wouldn't it make more sense to implement some method of identifying the desired content on the existing coderef element?
          >
          > Julio J. Vazquez
          > SDI Global Solutions
          >
          > --- In dita-users@yahoogroups.com, Dave Pawson <dave.pawson@...> wrote:
          >>
          >> http://norman.walsh.name//2012/04/21/textFragid
          >>
          >> One aspect of it. I think this would be useful in DITA for the reasons given
          >> in the article.
          >>
          >> regards
          >>
          >> --
          >> Dave Pawson
          >> XSLT XSL-FO FAQ.
          >> Docbook FAQ.
          >> http://www.dpawson.co.uk
          >>
          >
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • Jeremy H. Griffith
          On Sun, 22 Apr 2012 08:02:50 +0100, Dave Pawson ... Nice one, Dave! The RFC 5147 syntax: http://tools.ietf.org/html/rfc5147 also works nicely with the DITA
          Message 4 of 5 , Apr 22 2:37 PM
          View Source
          • 0 Attachment
            On Sun, 22 Apr 2012 08:02:50 +0100, Dave Pawson
            <dave.pawson@...> wrote:

            >http://norman.walsh.name//2012/04/21/textFragid
            >
            >One aspect of it. I think this would be useful in
            >DITA for the reasons given in the article.

            Nice one, Dave! The RFC 5147 syntax:
            http://tools.ietf.org/html/rfc5147
            also works nicely with the DITA coderef element.
            We've added support for it in the current DITA2Go
            Betas for dwhtm (HTML/XML outputs) and for dwrtf
            (Word RTF output).

            We also added four more PIs to handle the full
            RFC 5147 capabilities. We already had the
            ExtCodeStartLine and ExtCodeEndLine, and added
            ExtCodeStartChar and ExtCodeEndChar (offsets
            in characters, not bytes), and ExtCodeFileLen
            (length in bytes of the entire file, not the
            fragment) and ExtCodeFileEnc (encoding, optional).

            So the following two snippets do the same thing:

            <?dtall ExtCodeStartLine="4" ExtCodeEndLine="15"
            ExtCodeFileLen="438" ExtCodeFileEnc="UTF-8" ?>
            <codeblock><coderef href="fdkfunc.c" /></codeblock>

            <codeblock><coderef href="fdkfunc.c#line=3,15;length=438,UTF-8" /></codeblock>

            As Scott observed earlier, the fragment identifier
            is not required to have topicid/elemid in coderef
            as the target file is not necessarily DITA, so the
            latter usage does not conflict with the DITA spec.
            We'd recommend it over the PIs, and hope that other
            vendors, and the DITA-OT, also adopt it.

            Note that in RFC 5147, the starting line is actually
            the line number before the one you want (because it
            is zero-based). To start with the first line, use
            "#line=,15". In the PI, we stay one-based, like
            all text editors are.

            The RFC doesn't say what to do if both line and char
            offsets are present. So what we do is start with the
            starting line, then count to the starting char from
            there, and continue until the ending char (relative to
            the same place), or the ending line, whichever is first.
            This allows you to select a part of one or more lines
            easily, without having to count characters (which are
            code points, not bytes) to get to the starting line.

            The file length (bytes) provides a way of checking
            whether the file has changed since you specified
            the offsets in it. This is the same check Norm Walsh
            makes in Calabash for the Xinclude version. If the
            file size is provided and is not the same, we log an
            error and do not include any file content, per the RFC.

            Thanks again, Dave, for pointing this out.


            -- Jeremy H. Griffith <jeremy@...>
            DITA2Go site: http://www.dita2go.com/
          • Jarno Elovirta
            Hi, DITA-OT already supports extended format value: Extending support to use the RFC 5147 might be a
            Message 5 of 5 , Apr 22 11:33 PM
            View Source
            • 0 Attachment
              Hi,

              DITA-OT already supports extended format value:
              <coderef href="unicode.txt" format="txt; charset=UTF-8"/>
              Extending support to use the RFC 5147 might be a good idea.

              Cheers,

              Jarno

              On 2012-4-23 0:37, Jeremy H. Griffith wrote:
               

              On Sun, 22 Apr 2012 08:02:50 +0100, Dave Pawson
              <dave.pawson@...> wrote:

              >http://norman.walsh.name//2012/04/21/textFragid
              >
              >One aspect of it. I think this would be useful in
              >DITA for the reasons given in the article.

              Nice one, Dave! The RFC 5147 syntax:
              http://tools.ietf.org/html/rfc5147
              also works nicely with the DITA coderef element.
              We've added support for it in the current DITA2Go
              Betas for dwhtm (HTML/XML outputs) and for dwrtf
              (Word RTF output).

              We also added four more PIs to handle the full
              RFC 5147 capabilities. We already had the
              ExtCodeStartLine and ExtCodeEndLine, and added
              ExtCodeStartChar and ExtCodeEndChar (offsets
              in characters, not bytes), and ExtCodeFileLen
              (length in bytes of the entire file, not the
              fragment) and ExtCodeFileEnc (encoding, optional).

              So the following two snippets do the same thing:

              <?dtall ExtCodeStartLine="4" ExtCodeEndLine="15"
              ExtCodeFileLen="438" ExtCodeFileEnc="UTF-8" ?>
              <codeblock><coderef href="fdkfunc.c" /></codeblock>

              <codeblock><coderef href="fdkfunc.c#line=3,15;length=438,UTF-8" /></codeblock>

              As Scott observed earlier, the fragment identifier
              is not required to have topicid/elemid in coderef
              as the target file is not necessarily DITA, so the
              latter usage does not conflict with the DITA spec.
              We'd recommend it over the PIs, and hope that other
              vendors, and the DITA-OT, also adopt it.

              Note that in RFC 5147, the starting line is actually
              the line number before the one you want (because it
              is zero-based). To start with the first line, use
              "#line=,15". In the PI, we stay one-based, like
              all text editors are.

              The RFC doesn't say what to do if both line and char
              offsets are present. So what we do is start with the
              starting line, then count to the starting char from
              there, and continue until the ending char (relative to
              the same place), or the ending line, whichever is first.
              This allows you to select a part of one or more lines
              easily, without having to count characters (which are
              code points, not bytes) to get to the starting line.

              The file length (bytes) provides a way of checking
              whether the file has changed since you specified
              the offsets in it. This is the same check Norm Walsh
              makes in Calabash for the Xinclude version. If the
              file size is provided and is not the same, we log an
              error and do not include any file content, per the RFC.

              Thanks again, Dave, for pointing this out.

              -- Jeremy H. Griffith <jeremy@...>
              DITA2Go site: http://www.dita2go.com/



            Your message has been successfully submitted and would be delivered to recipients shortly.