Hello,

is there somebody out who can create a Open Source Komodo Edit dita
extension to get gui/css dita support working for Komodo Edit? That
would be great! Komodo Edit is Mozilla based. You should have
expertise how to create a xpi Mozilla extension(?)

Please, take a look at the "Komodo 4.0 Extensibility Challenge"

http://community.activestate.com/forum-topic/komodo-4-0-extensibility

cheers,

Karl

--- In dita-users@yahoogroups.com, "k.lodner" <k.lodner@...> wrote:
>
> Hello,
>
> there is a ongoing discussion how the Komodo Editor could provide
> auto-completion dita support.
>
> http://community.activestate.com/forum-topic/komodo-and-dita-support
>
> cheers,
>
> Karl
>
> --- In dita-users@yahoogroups.com, "k.lodner" <k.lodner@> wrote:
> >
> > Thanks a lot Eric. I missed that
> > http://docs.oasis-open.org/dita/v1.1/OS/dtd/ still contains the
> > catalog-dita.xml file.
> >
> > Anyway, KomodoEdit doesn't offer DITA code completion after adding the
> > catalog-dita.xml file. I will start a bug report to the ActiveState
> guys.
> >
> > Karl
> >
> > Eric Sirois <easirois@> wrote:
> > >
> > > Hi Karl,
> > >
> > > The catalog files are in the dtd and schema directories.  The file
> name
> > > is catalog-dita.xml.
> > >
> > > http://docs.oasis-open.org/dita/v1.1/OS/dtd/catalog-dita.xml
> > > http://docs.oasis-open.org/dita/v1.1/OS/schema/catalog.xml
> > >
> > > Eric
> > >
> > > k.lodner wrote:
> > > >
> > > > Hello,
> > > >
> > > > I planned to dive into all this XML stuff via DITA. Do you know
> how to
> > > > add a "Dita XML Catolog" to ActiveState's KomodoEdit? I can't find
> > > > such a catalog at http://docs.oasis-open.org/dita/v1.1/OS/
> > > > <http://docs.oasis-open.org/dita/v1.1/OS/>
> > > >
> > > > KomodoEdit: Edit > Preferences > Languages > XML catalogs?
> > > >
> > > > http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml
> > > > <http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml>
> > > >
> > > > ActiveState also migrates all their commercial Komodo IDE features
> > > > into a open source version available at http://www.openkomodo.org
> > > > <http://www.openkomodo.org>
> > > >
> > > > Thanks a lot,
> > > >
> > > > Karl
> > > >
> > > >
> > >
> >
>

Hello,

there is a ongoing discussion how the Komodo Editor could provide
auto-completion dita support.

http://community.activestate.com/forum-topic/komodo-and-dita-support

cheers,

Karl

--- In dita-users@yahoogroups.com, "k.lodner" <k.lodner@...> wrote:
>
> Thanks a lot Eric. I missed that
> http://docs.oasis-open.org/dita/v1.1/OS/dtd/ still contains the
> catalog-dita.xml file.
>
> Anyway, KomodoEdit doesn't offer DITA code completion after adding the
> catalog-dita.xml file. I will start a bug report to the ActiveState
guys.
>
> Karl
>
> Eric Sirois <easirois@> wrote:
> >
> > Hi Karl,
> >
> > The catalog files are in the dtd and schema directories.  The file
name
> > is catalog-dita.xml.
> >
> > http://docs.oasis-open.org/dita/v1.1/OS/dtd/catalog-dita.xml
> > http://docs.oasis-open.org/dita/v1.1/OS/schema/catalog.xml
> >
> > Eric
> >
> > k.lodner wrote:
> > >
> > > Hello,
> > >
> > > I planned to dive into all this XML stuff via DITA. Do you know
how to
> > > add a "Dita XML Catolog" to ActiveState's KomodoEdit? I can't find
> > > such a catalog at http://docs.oasis-open.org/dita/v1.1/OS/
> > > <http://docs.oasis-open.org/dita/v1.1/OS/>
> > >
> > > KomodoEdit: Edit > Preferences > Languages > XML catalogs?
> > >
> > > http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml
> > > <http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml>
> > >
> > > ActiveState also migrates all their commercial Komodo IDE features
> > > into a open source version available at http://www.openkomodo.org
> > > <http://www.openkomodo.org>
> > >
> > > Thanks a lot,
> > >
> > > Karl
> > >
> > >
> >
>

I agree with Julio here.  While the solution I posted will work, it's
really better to split the topics out into separate files.  By doing
that you bypass the complicated chunking configuration where you could
just use basic topicref nesting to get the same effect.

Eric

--- In dita-users@yahoogroups.com, "Julio Vaquez" <julio_v27612@...>
wrote:
>
> Hi Brian,
>
> I'm not sure why you have both topics in one file but my question
> becomes which topic does the first topicref to topicB.dita select when
> you don't specify the id? More appropriately, if you are truly using
> the topics in this manner why contain both in a single file in the
> first place?
>
> Julio J. Vazquez
> SDI
>
> --- In dita-users@yahoogroups.com, "authormf" <brian.whitehead@> wrote:
> >
> > I wonder if anyone can help me out with the DITA "chunk" attribute. I
> > have been playing around for days now and can not get it to perform as
> > I expect. I'm not entirely clear if the problem is my expectation, or
> > it does not work as documented. The documentation on the subject is
> > fairly sparse and unhelpful, but think I understand :-)
> >
> > To demonstrate my problem, here is a cut down version of the
> > situation. I know, ideally, I wouldn't start off from here, but there
> > is not a lot I can do about that :-(
> >
> > To generate HTML Help there are three topics, one with nested topics:
> > ------------------------
> > Topic_A.dita
> >
> > Topic_B.dita
> >    Topic_B1 (nested)
> >
> > Topic_C.dita
> > ------------------------
> >
> > This is how I want them to be structured and display in the Toc:
> > -----------------------
> > Topic_A
> >   |__Topic_B
> >   |   |__Topic_B1
> >   |
> >   |__Topic_C
> > -----------------------
> >
> > This is a model of the map I am using:
> > -----------------------
> > <topicref href="Topic_A.dita">
> >   <topicref href="Topic_B.dita " chunk="select-topic">
> >       <topicref href="Topic_B.dita#TopicB1 " chunk="select-topic"/>
> >   </topicref>
> >   <topicref href="Topic_C.dita "/>
> > </topicref>
> > ------------------------
> >
> > The result has the correct structure in the ToC (as above), but on the
> > page, Topic_B and Topic_B1 are shown concatenated as one large topic,
> > not as individual topics. The ToC links for Topic_B and Topic_B1 both
> > point to the top of the concatenated topic.
> >
> > My understanding of the attribute chunk=select-topic is that it will
> > extract only the topic identified in the topicref and exclude its
> > ancestors, peers or descendents, but that is not happening. Can anyone
> > identify where I am going wrong, or is it a bug?
> >
> > Many thanks
> >
> > Brian
> >
>

Hi Brian,

I'm not sure why you have both topics in one file but my question
becomes which topic does the first topicref to topicB.dita select when
you don't specify the id? More appropriately, if you are truly using
the topics in this manner why contain both in a single file in the
first place?

Julio J. Vazquez
SDI

--- In dita-users@yahoogroups.com, "authormf" <brian.whitehead@...> wrote:
>
> I wonder if anyone can help me out with the DITA "chunk" attribute. I
> have been playing around for days now and can not get it to perform as
> I expect. I'm not entirely clear if the problem is my expectation, or
> it does not work as documented. The documentation on the subject is
> fairly sparse and unhelpful, but think I understand :-)
>
> To demonstrate my problem, here is a cut down version of the
> situation. I know, ideally, I wouldn't start off from here, but there
> is not a lot I can do about that :-(
>
> To generate HTML Help there are three topics, one with nested topics:
> ------------------------
> Topic_A.dita
>
> Topic_B.dita
>    Topic_B1 (nested)
>
> Topic_C.dita
> ------------------------
>
> This is how I want them to be structured and display in the Toc:
> -----------------------
> Topic_A
>   |__Topic_B
>   |   |__Topic_B1
>   |
>   |__Topic_C
> -----------------------
>
> This is a model of the map I am using:
> -----------------------
> <topicref href="Topic_A.dita">
>   <topicref href="Topic_B.dita " chunk="select-topic">
>       <topicref href="Topic_B.dita#TopicB1 " chunk="select-topic"/>
>   </topicref>
>   <topicref href="Topic_C.dita "/>
> </topicref>
> ------------------------
>
> The result has the correct structure in the ToC (as above), but on the
> page, Topic_B and Topic_B1 are shown concatenated as one large topic,
> not as individual topics. The ToC links for Topic_B and Topic_B1 both
> point to the top of the concatenated topic.
>
> My understanding of the attribute chunk=select-topic is that it will
> extract only the topic identified in the topicref and exclude its
> ancestors, peers or descendents, but that is not happening. Can anyone
> identify where I am going wrong, or is it a bug?
>
> Many thanks
>
> Brian
>

Is content management important?

Do you manage your content using a content management system?

• Yes
• No

Is structure important?

Do you structure your content? Do you have an information architecture (e.g., a taxonomy)? Do you have a document architecture (e.g., content model)?

• Information architecture and document architecture
• Information architecture (e.g., taxonomy)
• Document architecture (content models)
• Unstructured content

Is content reuse important?

How much of your content gets reused in other contexts?

• A lot
• Some
• A little
• None

Is single-sourcing important?

Do you publish content to multiple output formats and channels (e.g., web/HTML and print/PDF)?

• Yes
• No

Is translation/localization important?

Is your content multi-lingual?

• Yes
• No

Do you markup your content?

Does your content have metadata?

• Semantic, structural, and style tags
• Structural and style tags
• Style/format/presentation/layout tags only

Is your content modular?

Is your content created in small chunks/topics?

• Yes. (content is readable in any order, like help topics)
• No. (content is long linear narrative)

Is your content conditional?

Do you serve different content to different audiences?

• Yes
• No

Is your content task-oriented and minimalist?

Do you follow these documentation best practices?

• Minimalist and task-oriented
• Task-oriented
• Minimalist
• Neither

Is standardization important?

Do you want to use practices that are shared in your industry/profession?

• Yes
• No

To see how your D.Q. compares to industry averages, check out DITA Quotients - available once we have collected some data.

Thanks a lot Eric. I missed that
http://docs.oasis-open.org/dita/v1.1/OS/dtd/ still contains the
catalog-dita.xml file.

Anyway, KomodoEdit doesn't offer DITA code completion after adding the
catalog-dita.xml file. I will start a bug report to the ActiveState guys.

Karl

Eric Sirois <easirois@...> wrote:
>
> Hi Karl,
>
> The catalog files are in the dtd and schema directories.  The file name
> is catalog-dita.xml.
>
> http://docs.oasis-open.org/dita/v1.1/OS/dtd/catalog-dita.xml
> http://docs.oasis-open.org/dita/v1.1/OS/schema/catalog.xml
>
> Eric
>
> k.lodner wrote:
> >
> > Hello,
> >
> > I planned to dive into all this XML stuff via DITA. Do you know how to
> > add a "Dita XML Catolog" to ActiveState's KomodoEdit? I can't find
> > such a catalog at http://docs.oasis-open.org/dita/v1.1/OS/
> > <http://docs.oasis-open.org/dita/v1.1/OS/>
> >
> > KomodoEdit: Edit > Preferences > Languages > XML catalogs?
> >
> > http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml
> > <http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml>
> >
> > ActiveState also migrates all their commercial Komodo IDE features
> > into a open source version available at http://www.openkomodo.org
> > <http://www.openkomodo.org>
> >
> > Thanks a lot,
> >
> > Karl
> >
> >
>

Erik Hennum wrote:
> Though highlighted in red, the links on the page should all resolve to
> subordinate documents. Because the content was pasted straight from HTML
> into the wiki HTML editor, the formatting leaves a lot to be desired. In
> particular, the design example and model representation aren't easy to
> understand with the wiki formatting.

Wiki markup usually allows for pre-formatted text markup.  Does the DITA
Wiki support that feature?


Ben

For a client where we need to enable the transparent *authoring* of
XML-based documents in InDesign and InCopy I've been doing some proof of
concept work on going directly to and from InCopy's INCX format (rather
than trying to import the XML into InCopy/InDesign and maintain the
original tagging there, which is essentially impossible in the general
case, because the tagging is too easy to hose up if you turn tags off in
InCopy and the tags are too intrusive if you turn tags on in InCopy and
in any case, many authors can't be expected to understand the markup at
all anyway)..

InCopy is a companion to InDesign that is essentially the InDesign story
editor. You can use it either standalone to create content that is
styled but not integrated with a full InDesign document (meaning you get
a rough galley view of the styled content but not a full paged WYSIWYG
view of the final document) or through InDesign, where you can see the
composed pages but not modify the pages themselves, only the content.

It's a very handy tool because it allows authors and editors to create
content without danger of them messing about with the layout. It's also
inexpensive, about $250.00 for a single license. It also provides some
basic collaboration features, such as a simple lock mechanism to prevent
the same file being modified by two users at once.

Another nice feature is that InCopy's native format is XML, the INCX
format, which is a stripped-down variant of the InDesign interchange
format (INX). So users don't have to do anything special to save as XML
(as they do in InDesign)

It turns out that it's actually relatively easy to read and write INX
using XSLT, despite the surface opacity of the INX markup. With XSLT 2's
for-each-group feature and the ability to write functions in your
transform it is not too hard to interpret untagged InCopy content into
tagged XML (you could, of course, also take advantage of any tagging in
the InCopy content as well, although I'm finding that InDesign's XML
feature is still too limited to be worth the effort, especially when
going straight from the INCX/INX data is as easy as it is).

The work I've done so far is crude (and part of a client project so I
can't give it away) but I've demonstrated that I can go from InDesign
styled content (no tagging) to DITA and back to InCopy without loss of
formatting, by using three tricks:

- Use the outputclass= attribute to capture any InDesign style
information that is not derivable from the element and its context
(e.g., style overrides, unexpected InDesign styles, etc.).

- Capture things like InMath equations or non-linked graphics as raw INX
markup within a DITA <foreign> element.

- Maintain a config file for all the InDesign styles so you can map from
style object references to style names and back again (this will make
sense as soon as you try to implement this type of mapping). I just
created a simple XQuery that dumps out a catalog of all the styles in an
INX file. The key to this trick is that when you place an InCopy
document into InDesign, it matches the styles used in InCopy to the
styles in the InDesign document by style name, not style object ID, so
you just need to maintain the style name in any InCopy-to-DITA-to-InCopy
round trip--you don't have to recreate the original object IDs used in
the original INCX file.

The main challenge I'm running into is managing white space: InDesign is
very sensitive to white space, so you have to make sure you don't emit
any whitespace you don't actually want and you have to carefully control
where you emit new lines or paragraph markers (\u2029).

This INX-based approach seems a lot easier than using InDesign's native
XML import/export mechanism, which has all sorts of limitations.

If you were trying to generate a full InDesign document via this method,
where you didn't know how many pages and frames the content would need
or you needed to synthesize frames dynamically, you'd still need
InDesign scripting or hand work to lay out the content from a generated
InCopy file, but that would be totally doable using well-understood
InDesign scripting techniques.

Another key aspect of using InCopy is that you can create an InDesign
document that provides all the necessary pages and frames and then place
an InCopy document into those frames (assuming they're threaded as a
single sequence of frames) as a link (which is the default behavior).
You can then update or regenerate the InCopy file and just update the
link in InDesign to get the content.

For example, you would typically make each section that starts a new
page into a separate InCopy article and then link those into your
InDesign pages (for example, in the context of a DITA bookmap, a chapter
would generate an InCopy article with just the chapter title and any
content before the first subsection, then you'd have an InCopy article
for each subsection and so on). The main thing is that each InCopy
article maps to exactly one sequence of threaded frames (and note that
you can use explicit frame-break characters to force content to go to a
next frame, for example, to force the content following a title to go
from the title's frame to the body frame in a page design where the
title has to be (or is) in a separate frame--you're not limited to doing
all placement and positioning using paragraph styles).

This means you could have a workflow where you author in DITA, generate
an InCopy representation of the content, place it in an InDesign
document to lay it out once the content is complete enough that there
won't be too much risk of rework of the layout, then regenerate the
InCopy document whenever the source XML changes. Since the generation of
the InCopy article is via an XSLT script it could be easily integrated
with pretty much any DITA-aware editor without too much trouble or done
as a side effect of commit back to a source control system or whatever.

Anyway, if anyone has been struggling with getting DITA either from
InDesign or to InDesign, this seems like a very promising approach,
especially where you need to enable authoring in InCopy but want to keep
XML as the authoritative source of the content.

Cheers,

Eliot

--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com

Hi Andy - the old ditaval files should continue to work with 1.4.1,
although eventually you'll want to update to the new format.

If you are not using any flagging, then your files may not need to change;
the filter portion is pretty much the same. There are new elements for
flagging and alternate image text though. The details of the new elements
are in the DITA 1.1 specification here:
http://docs.oasis-open.org/dita/v1.1/CS01/langspec/common/about-ditaval.html

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

dita-users@yahoogroups.com wrote on 04/17/2008 03:31:13 PM:

> Hi all,
> I am migrating from OT 1.2.2/DITA 1.0 to OT 1.4.1/DITA 1.1.
> I am looking for more info on the changes to the DITAVAL standard
> support in OT 1.4.0. Is there a summary of what changed and what it
> means to my DITAVAL files?
> Thanks in advance,
> Andy Hall
> Algorithmics
>
>
>

Hi Dick and Chris,

I am getting the same error:

    "java.io.FileNotFoundException:
file:\C:\DITA-OT1.4.1\temp\DITA-readme_MERGED.xml"

error when, after running 'ant -f integrator.xml', I try to generate
the sample PDF file with:

   java -jar lib/dost.jar /i:doc/DITA-readme.ditamap /transtype:pdf2

Was this problem ever resolved?

thanks,

-john

--- In dita-users@yahoogroups.com, "a.vanraaphorst9"
<avanraaphorst@...> wrote:
>
> --- In dita-users@yahoogroups.com, "Christopher Wong" <chris@> wrote:
> >
> > This seems to suggest that the merged file is missing. This
> > sequence_MERGED.xml file is generated by the preprocessor pipeline
> > prior to invoking the PDF2 transforms.
> >
> > 1. Make sure you have run the integration task (ant -f
> > integrator.xml).
> >
> > 2. See messages preceding those you have posted to see if there is
> > any hint as to why the merged file is not being generated.
> >
> > Chris
> >
>
> I did definitely run integrator.xml.
>
> I don't see any messages indicating why the merged file is missing.
>
> If I replace the <pipeline> call the plugin uses to create the merged
> file with an equivalent <xslt> call (which all the other targets use in
> 1.4.1), the merged file is created.
>
> I can install the plugin and run it with no change in OT 1.4.
>
> In either 1.4 or 1.4.1, once the merged file is created, I now get a
> bunch of errors from XEP when it tries to render the pdf file.
>
> Does any of this make any sense?
>
> Regards,
>
> Dick Johnson
>

I just noticed the dropdown by search window. Is that a new eclipse
thing that I haven't seen yet or is that something they added on? In
either case, it's very cool.

David

--- In dita-users@yahoogroups.com, "cramerdw" <david@...> wrote:
>
> Yeah, I like how they're able to have some content available to the
> general public and some that requires a login in the same infocenter.
> I assume they've modified the search so that you only get hits from
> the public stuff if you're not logged in. Anyway, nice.
>
> The links to the feedback and errata forms at the bottom that
> prepopulate the form with data about the topic you're on is good too.
> And any use of RSS makes me happy.
>
> I'm not seeing any problems in Firefox.
>
> At least some of the docs were generated from docbook content:
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/Babcdjha.html
>
> <meta name="generator" content="DocBook XSL Stylesheets V1.69.1" />
>
> David
>
> --- In dita-users@yahoogroups.com, Eric Sirois <easirois@> wrote:
> >
> > It looks like they have made some tweaks to the infocenter as well.
> > Some of the enhancements look really cool.
> >
> > Does anyone know who developed the tweaks.  It seems to be working
fine
> > in IE, but the right hand side of the screen is cutoff in Firefox.
> >
> > Eric
> >
> > Bob Beims wrote:
> > >
> > > For those of you involved in the semiconductor industry, you
might be
> > > interested in this web site:
> > >
> > > http://infocenter.arm.com/ <http://infocenter.arm.com/>
> > >
> > > A quick look under the hood shows that this content appears to be
> > > delivered via the open toolkit's eclipse help transform. And it is
> > > obviously delivered on the web via an Eclipse server environment.
> > >
> > > If anyone from ARM is listening, congratulations on the excellent
> > > delivery of your content via DITA.
> > >
> > > And if anyone from ARM is listening, I'd like to invite you to
> > > participate in the DITA TC Semiconductor Information Design
> > > Subcommittee ...
> > >
> > >
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-sidsc
> > >
> <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-sidsc>
> > >
> > > You could obviously contibute a great deal to our cross-industry
> > > standardization efforts, while at the same time leveraging the work
> > > of the other member companies.
> > >
> > > Regards,
> > > Bob Beims
> > >
> > > OASIS DITA TC SIDSC Chair
> > >
> > >
> >
>

One note about the "bookish" look of the FM authoring view .. the
WYSIWYG formatting and layout is completely under your control. The
default structure applications do have a page-based layout, but there's
nothing stopping you from customizing that look to suit your needs. I
once went to the effort of making a structure application that
completely morphed from online to print based on the setting of an
attribute value on the root element, so the authors could choose the
view that they wanted to write in.

Also .. I'd like to clarify the misconception of FM's use of
intermediate files in the XML authoring process. It works just like any
XML editor in that you select an XML file to edit, it opens in FM for
authoring, and when you save, it directly updates the same XML file ..
no intermediate files or additional steps. This can be done with DITA
files using FM7.1 and up.

Cheers,

...scott



Troy Klukewich wrote:
> Hi:
>
> I would second the notion that when speaking of Frame's DITA and XML
> support, former 7.2 users should really look at Frame 8. It is a huge
> improvement. In evaluating Frame previous to version 8, I readily
> rejected it due to its reliance on binary sources and intermediary
> formats. The most recent version works happily with native DITA and
> XML files.
>
> I thought it only fair that I look at the most recent version.
>
> <quote>
> There's nothing in the FrameMaker DITA implementation that makes it
> more of a book paradigm than any other XML editor.
> </quote>
>
> Out of the box, it did present a "book" view for WYSIWYG based no
> doubt on the impressive PDF generation with margins, pages, and page
> numbers. Considering that my topic structure was targeted for online
> help, the book presentation was irrelevant and even misleading. I did
> not investigate how to turn off this treatement, but I did think of it
> as a throw-back to the book days.
>
> Otherwise, it seems like a viable option. If I were reevaluating Frame
> today, I would certainly put it in the mix with Arbortext, XMetal, and
> oXygen, my personal short list of DITA editors.
>
> Troy Klukewich
> Information Architect
> Oracle
>
>
>
> ----- Original Message ----
> From: Scott Prentice <sp@...>
> To: dita-users@yahoogroups.com
> Sent: Tuesday, April 15, 2008 9:57:21 AM
> Subject: Re: [dita-users] Re: Structured Frame vs. XMetal
>
> Hi Rob...
>
> I just want to respond to some of your FrameMaker issues. You may want
> to take a look at the features provided in the latest version of
> DITA-FMx .. it has changed significantly since the early FM7.2 versions.
>
> There's nothing in the FrameMaker DITA implementation that makes it more
> of a book paradigm than any other XML editor. You can author single
> topic files and maps that support whatever type of organization that you
> want. FM does provide some print book features that you may want to make
> use of, but there's nothing that forces that on you.
>
> <snip>
>
> I've set up a chart that compares the DITA features in FM8 DITA vs.
> DITA-FMx .. if anyone can provide data on other editors, I'll add more
> columns ..
>
> http://www.leximati on.com/dita- fmx/featurecompa rison.php
> <http://www.leximation.com/dita-fmx/featurecomparison.php>
>
> Cheers,
>
> ...scott
>
> .
>
>
>

Hi Kris,

I have always referred to "code reviews" for XML as "tag edits." I tell my clients that tag edits are an essential part of the writing process regardless of which XML DTD is being used (for example: DITA, DocBook, or SD1000). Tag edits accomplish the following:

• Ensure that the tagging is appropriate for the content. For example, you might discover that somebody used an "ol" inside of a concept topic to document a task. At a lower level, you may find that a writer is ignoring a tag's semantic intent to achieve a formatting effect.
• Verify that the tagging complies with local markup practices or policies. Establishing these practices is often time consuming; however, if your company has several writers using XML it will significantly increase the degree to which you can achieve a common look and feel across your documentation sets.
• Improve structural consistency. In the case of DITA, this means scrutinizing the structures that emerge from the DITA maps. The idea is make sure that the structures are not arbitrarily different from other publications in the documentation set.

Tag edits are also the core of a successful writer mentor program. The mentor process ought to be primarily based on frequent tag edits.

Bob Thomas
President
Tagsmiths, LLC
+1 720 201 8260

Hi Alex,

I believe that it has to be included in the ditamap.  We ran into the
same issues during our development cycle.  We started off with XHTML
output and did not have any issues or errors.  Once we started to create
PDFs we were getting a lot of errors.  They were all related to this
exact scenario.  Topics referencing other topics  that were not in the
map.  Needless to say our IA has a dislike for xrefs and we have build
reports that check for these types of links.

For PDF the processor uses the map to determine the order of the topics.
It uses that order to determine page numbering.  If the linked topic is
not in the map, the PDF processor does not know where to place that
topic in the "book". Any index entries in that topic also need to have a
page number associated with it as well.

Eric

Alex Gerasimov wrote:
>
> Hi! I'm using xref to link another topic to the existing one; I use
> DITAOT to publish these topics using two ways: the first is to include
> both topics into the ditamap; the second is just to publish the first
> topic. The produced result is different: the link to the second topic
> is clickable and leads to the second topic included into the pdf as an
> internal element when a ditamap is used. But if I use just a topic for
> publishing the second topic is not included into the result pdf as an
> internal element.
>
> The question is - is it possible at all to include the xrefed topic
> into the result pdf without ditamap usage? Or is the only way to
> implement is to use a ditamap?
>
> Thanks, Alex
>
>

"Kristen James Eberlein" keberlein@... wrote:

> I'd be really interested in knowing who (other than IBM Silicon
> Valley Lab) is implementing DITA code reviews -- and some
> specific details of how their company or division is implementing
> them. Have DITA code reviews been helpful for your group? Have
> some aspects been difficult?


My group does this for DocBook documents. Only a few topics are reviewed
as each author starts working in DocBook for the first time. It has
helped us catch some problems early, and to identify who needs a little
extra guidance in learning how to tag correctly.


*************************
Rob Cavicchio
Principal Technical Writer
EMC Captiva
EMC Corporation
10145 Pacific Heights Boulevard, 6th Floor
San Diego, CA 92121-4234

P: (858) 320-1208
F: (858) 320-1010
E: Cavicchio_Rob@...

The opinions expressed in this message are my own and should in no way
be interpreted to reflect the opinions of EMC.

Hi! I'm using xref to link another topic to the existing one; I use
DITAOT to publish these topics using two ways: the first is to include
both topics into the ditamap; the second is just to publish the first
topic. The produced result is different: the link to the second topic
is clickable and leads to the second topic included into the pdf as an
internal element when a ditamap is used. But if I use just a topic for
publishing the second topic is not included into the result pdf as an
internal element.

The question is - is it possible at all to include the xrefed topic
into the result pdf without ditamap usage? Or is the only way to
implement is to use a ditamap?

Thanks, Alex

Hi Karl,

The catalog files are in the dtd and schema directories.  The file name
is catalog-dita.xml.

http://docs.oasis-open.org/dita/v1.1/OS/dtd/catalog-dita.xml
http://docs.oasis-open.org/dita/v1.1/OS/schema/catalog.xml

Eric

k.lodner wrote:
>
> Hello,
>
> I planned to dive into all this XML stuff via DITA. Do you know how to
> add a "Dita XML Catolog" to ActiveState's KomodoEdit? I can't find
> such a catalog at http://docs.oasis-open.org/dita/v1.1/OS/
> <http://docs.oasis-open.org/dita/v1.1/OS/>
>
> KomodoEdit: Edit > Preferences > Languages > XML catalogs?
>
> http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml
> <http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml>
>
> ActiveState also migrates all their commercial Komodo IDE features
> into a open source version available at http://www.openkomodo.org
> <http://www.openkomodo.org>
>
> Thanks a lot,
>
> Karl
>
>

Hi Jennifer,

--- In dita-users@yahoogroups.com, "Linton, Jen" <jennifer.linton@...>
wrote:
> I would be happy to share if you want to know how we customized our
XSL template.

it would be great if you could share them with me. I'm having a look
at the existing XSL now to get an idea of the structure. Your answer
hints at cross references being handled separately in a distinct
stylesheet. What reference did you use in order to customise the XSL?
Is this done through a 'plug-in' architecture or am I confusing two
things and that is just for specializations?

Richard

Hello,

I planned to dive into all this XML stuff via DITA. Do you know how to
add a "Dita XML Catolog" to ActiveState's KomodoEdit? I can't find
such a catalog at http://docs.oasis-open.org/dita/v1.1/OS/

KomodoEdit: Edit > Preferences > Languages > XML catalogs?

http://www.activestate.com/Products/komodo_ide/komodo_edit.mhtml

ActiveState also migrates all their commercial Komodo IDE features
into a open source version available at http://www.openkomodo.org

Thanks a lot,

Karl

I wonder if anyone can help me out with the DITA "chunk" attribute. I
have been playing around for days now and can not get it to perform as
I expect. I'm not entirely clear if the problem is my expectation, or
it does not work as documented. The documentation on the subject is
fairly sparse and unhelpful, but think I understand :-)

To demonstrate my problem, here is a cut down version of the
situation. I know, ideally, I wouldn't start off from here, but there
is not a lot I can do about that :-(

To generate HTML Help there are three topics, one with nested topics:
------------------------
Topic_A.dita

Topic_B.dita
    Topic_B1 (nested)

Topic_C.dita
------------------------

This is how I want them to be structured and display in the Toc:
-----------------------
Topic_A
   |__Topic_B
   |   |__Topic_B1
   |
   |__Topic_C
-----------------------

This is a model of the map I am using:
-----------------------
<topicref href="Topic_A.dita">
   <topicref href="Topic_B.dita " chunk="select-topic">
       <topicref href="Topic_B.dita#TopicB1 " chunk="select-topic"/>
   </topicref>
   <topicref href="Topic_C.dita "/>
</topicref>
------------------------

The result has the correct structure in the ToC (as above), but on the
page, Topic_B and Topic_B1 are shown concatenated as one large topic,
not as individual topics. The ToC links for Topic_B and Topic_B1 both
point to the top of the concatenated topic.

My understanding of the attribute chunk=select-topic is that it will
extract only the topic identified in the topicref and exclude its
ancestors, peers or descendents, but that is not happening. Can anyone
identify where I am going wrong, or is it a bug?

Many thanks

Brian

Troy Klukewich wrote:
> I would second the notion that when speaking of Frame's DITA and XML
> support, former 7.2 users should really look at Frame 8. It is a huge
> improvement. In evaluating Frame previous to version 8, I readily
> rejected it due to its reliance on binary sources and intermediary
> formats. The most recent version works happily with native DITA and
> XML files.
FrameMaker 7.2 will work with native XML and DITA by setting some flag.
I saw this in a book from Kay Whatley but cannot remember the details.
I would highly recommend the latest release of DITA-FMx from Leximation
over the FM 7.2 or 8 Adobe DITA plug-in, so you may not have to upgrade
from FM 7.2 to 8.0.  It offers much more functionality, e.g. the ability
to create a workbook of DITA XML files and perform global search and
replace over them, and  other batch tasks.

If you are comfortable with FM formatting configuration, you can start
with the FM template file and create your own template for
specialisations, bypassing the whole messy XSL-FO route altogether.
FM's nifty ability to apply master pages depending on a particular
element or para style can automate your page applications.

At the moment, if you do a book, you have to add the frontmatter and
generated files in unstructured FrameMaker, but you can mix these files
with the structured body of the book.  Come support for DITA 1.1 with
bookmap and niftier index elements and all this will go away.

Regards,
Hedley

--

Hedley Finger

28 Regent Street   Camberwell VIC 3124   Australia
Tel. +61 3 9809 1229   Fax. (call phone first)
Mob. (cell) +61 412 461 558
Email. "Hedley Finger" <hfinger@...>