Re: [dita-users] On xInclude
- View SourceHi,
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.
On 2012-4-23 0:37, Jeremy H. Griffith wrote:
On Sun, 22 Apr 2012 08:02:50 +0100, Dave Pawson
>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:
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/