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

Re: [dita-users] Re: On xInclude

Expand Messages
  • dave.pawson
    I find this approach works well, for XML or (now) plain text. http://dpawson.co.uk xslt xsl-fo docbook FAQ
    Message 1 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 2 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 3 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.