🚀 go-pugleaf

Hi David...

Yuck.

I think you're looking at some complex XSLT import/export process and/or custom plugin development.

So .. you're trying to insert each "Widget" into a data model of your own that acts as a container for each basic widget description plus a more verbose description. You're not trying to stuff additional data into the base MakeWidget model, right?

I may be too DITA-focused, but I think that with a little (or a lot) of work, you could actually do this with DITA. DITA's specialization feature lets you create a data model that uses the element names of your choosing as long as it falls into a structure that DITA supports. Your MakeWidget model looks pretty basic and should fit into an existing DITA construct.

You could then define a container model for this (using base DITA elements or a specialization), and pull in each Widget as a conref. By doing this you wouldn't need to separate or merge anything .. the conreffed widgets would show up inline within the uber description, while remaining intact within the original MakeWidgets file. You would need to be able to add an "id" attribute to each widget as well as the top level component element .. possible?

Or .. maybe I'm just crazy. :)

...scott

Scott Prentice
Leximation, Inc.
www.leximation.com

Hi Scott;

      So .. you're trying to insert each "Widget" into a data model of your
      own that acts as a container for each basic widget description plus a
      more verbose description. You're not trying to stuff additional data into
      the base MakeWidget model, right?




Close enough. And yup, I'm pretty sure I can do this with DITA and conrefs... except for that fact that the "MakeWidget" tool the engineers must use won't accept DITA.

See my footnote. DITA is TW oriented and High Tech XML formats are eng driven. The engineers must use their own non-DITA XML structure in order to make Widgets. This is a hard constraint. So either you don't use DITA or you constantly swap between eng XML and DITA - extremely hard to do - and track info in 2 places. Also hard to do.

IMHO, this is one of the fundamental flaws of DITA. Raw engineering XML contains usable doc info . Thus, the future of reuse is databases between engineer and TW, not databases between TW and TW. An eng datum is a TW doc.

There's probably a paper in there somewhere, but "Why I hate DITA" may get me shot at STC conferences and I like living... ;)

See also XLink, Ted Nelson's Xanadu, and Transclusion for those interested in related topics.

David Blyth (the UNIX and vi dinosaur)
Staff Technical Writer
QCT Division
QUALCOMM - Standard Disclaimers Apply

Only 149,999,950 more years of Ruling The Earth to go
--------------------------------------------------------------- --

But how does the MakeWidget SW know that the XML is "DITA" if the element names are as needed. I can make a DITA specialization that uses the exact names of the elements you describe above. The root "topic" ModifiedComponent, can contain "topics" Widget and LongDescription, which in turn contain the other requisite elements. The Component model can also be consumed by a DITA-aware XML editor provided that the proper (fairly simple) specialization was developed. The only thing that I could see causing a problem is the requirement of an @id attribute on each "topic" .. if that can't be accommodated by the Widget model, then it won't work (that is unless you want to have some intermediate XSLT conversion between the two worlds).

No?

...scott

David, I hope you don't get shot, because that would definitely cause me to hesitate before criticizing DITA again. So far, though, the most that has happened is that I've been likened to the sun-revolves-around-the-earth level of enlightenment. That sucks too, but it's better than a bullet.

Russ

Hi again;

      I can make a DITA specialization that uses the exact names of the elements
      you describe above. The root "topic" ModifiedComponent, can contain "topics"
      Widget and LongDescription, which in turn contain the other requisite
      elements.




Scott, I'm not sure I follow this. The actual "Widget" element I'm working with must contain non-DITA elements as it follows some other standard (sorry, but I have to be cagey about some specifics).

      <component>




<widget>
      <bizarro>Blah</bizarro>
      <fruitcake>Fred</fruitcake>
    </widget>

</component>

So if "bizarro" and "fruitcake" aren't DITA compliant, how does widget become a DITA-compliant topic? I doubt that widget can support an "id" attribute but getting closer would still be interesting. Can you cite an example? Thanks!

Russ, I thought the sun couldn't revolve around the earth because the heat would singe the turtle when the sun got too close. ;|

David Blyth (the UNIX and vi dinosaur)
Staff Technical Writer
QCT Division
QUALCOMM - Standard Disclaimers Apply

Only 149,999,950 more years of Ruling The Earth to go
-------------------------------------------------------------------

Hi David...

Yes .. that's one of the cool things about DITA is that you don't have to use the default element names, you can make up whatever element names you want to use as long as they can be mapped back to the core DITA topic-based structure. This is the concept of specialization. In your hypothetical model ..

<component>
    <widget>
      <bizarro>Blah</bizarro>
      <fruitcake>Fred</fruitcake>
    </widget>
</component>

both component and widget would each be a "topic" element, bizarro would be a "title" and and shortcake would be a "shortdesc". Hmm .. although since a "topic" always needs a "title", it may be necessary to define a title for the component topic. If you could specialize the "dita" element, you could map component to that, but I don't think they allow specialization of "dita". Without seeing your real model, or one that provides the right structure with the names changed to protect the innocent, we could determine if it is really possible to create a "widget" specialization.

My point is, don't get caught up in the element names that are presented by default DITA. If you can make use of the features that DITA provides, you may be able to use DITA even if your model seems to be completely different.

Cheers,

...scott