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

Re: [xml-doc] Maintenance and Duplication Problems

Expand Messages
  • Brigit van Loggem
    ... Word can do a lot more than many are aware of. In this particular case, set custom document properties for version number etc and insert fields to
    Message 1 of 21 , Jun 6 12:29 AM
    • 0 Attachment
      Roger wrote:

      >providing links, but sometimes links are burdensome or impractical. For
      >example, software documentation may refer to the version number many times.
      >It would be both burdensome and impractical to provide a link to the version
      >number. Another example is terminology that changes as the software
      >evolves.

      Word can do a lot more than many are aware of. In this particular case, set
      custom document properties for version number etc and insert fields to
      reference them.

      I don't particularly like Word, but it's pretty good at being automated.
      Its programmability is amazing.

      HTH,
      -Brigit

      Byte Ryte bv
      http://www.byteryte.nl
    • Martin WHEELER
      ... Yeah. It s just such a pity that the major use of this programmability is for propagating malicious viruses; [as anyone who has had to clean up after Word
      Message 2 of 21 , Jun 6 1:51 AM
      • 0 Attachment
        On Wed, 6 Jun 2001, Brigit van Loggem wrote:

        > I don't particularly like Word, but it's pretty good at being automated.
        > Its programmability is amazing.

        Yeah. It's just such a pity that the major use of this programmability
        is for propagating malicious viruses; [as anyone who has had to clean up
        after Word users will attest].

        The best-ever tagging software which could have been applicable to the
        puposes being discussed is (was?) Ventura Publisher -- now unfortunately
        fallen into the wrong hands, and so presumably doomed to be quietly
        strangled.
        --
        Martin Wheeler - StarTEXT - Glastonbury - BA6 9PH - England
        mwheeler@... http://www.startext.co.uk/

        www.gateway.gov.uk -- the UK government's £18M Microsoft-only website
        -- "all your government's databases are now belong to us" --
      • Barry A. Schaeffer
        We have run into two distinct challenges in the management of shared content: 1. Shared material such as warnings, cautions, boilerplate, etc. These content
        Message 3 of 21 , Jun 6 6:11 AM
        • 0 Attachment
          We have run into two distinct challenges in the management of shared content:

          1. Shared material such as warnings, cautions, boilerplate, etc.
          These content elements can be recognized by the fact that while they may be appropriate for inclusion in multiple documents, they do not "belong" to any of them. The import of that status, of course, is that no author using them in his or her document has the authority to change them. Usually, especially in the aerospace and legal worlds, each sharable element is "owned" by an author responsible for the content of various shared elements.

          In these cases, we have found that the most effective method of dealing with sharing is to group sharable element on some logical premise, store them together and direct links (or entity references) to them from wherever they are to be included.

          In this endeavor, we have found that two functions are particularly useful:

          a. Use of a link authoring and management tool that presents
          available link targets to an author searching for a shared
          element. This function should also protect links from breakage
          by actions at the target side. In fact, no action should be
          possible at the target of a link without the involved author being
          notified of that fact and being given information about the links
          at risk.

          b. Use of a tool or function that records usage so that "where used"
          reports may be generated to aid the owners of shared elements
          in assessing the impact of changes to these elements, and to
          know the places in the repository at which some change may
          be required to accommodate such changes.

          2. Documents that are intended to serve different audiences and/or functions but that contain a high degree of common data. The classical way this was supported was through maintenance of a document file for each variant, with editorial updates to keep the common data in proper synch.

          Our experience has been that this challenge is actually more demanding than the one above because variants can occur at any level and often does not lend itself to the definition of sharable elements. We have seen firms facing variant management challenges for equipment models, skill levels, software releases, output media, public/restricted publications, automobile model years, and in a few cases, most of the above simultaneously.

          We have been working with a concept called, in the aircraft industry, "effectivity" since 1995. Ford, for instance, keeps 12 years of owners manuals live for each of its auto models. Through effectivity, since 1996, all versions of each manual are authored and managed from single SGML document file. The obvious advantages to this approach where it's appropriate are:
          a. Common data is not duplicated and, thus, does not get out of synch
          between variants.

          b. All authoring for all variants of a document takes place in a single
          file, making the author's task more coherent and managable.

          c. The need to break documents down into small incrments is
          obviated, materiall reducing the complexity of the data
          management challenge (we have found this one to be
          major.)

          The most effective environment we have seen is a mix of the two devices described above. Through sharable elements, any widely shared content can be managed centrally but used locally. Through effectivity, any content in a document (down to a single character) can be tagged so that it is included only in those variants for which it is appropriate. Because effectivity can be used on both text and elements, even sharable elements such as graphics can be tagged so that different versions are included in different variants of a document.

          We have a significant amount of experience with these functions because we have, at clients's urging over the years, developed widely-used applications tools, part of a suite, that support them in the Arbortext environment. We have seen, repeatedly, sites get mixed up in the definitions of "sharing" and "reuse" ending up with a real hodge-podge that is difficult to author and even more difficult to manage. We have also seen sites try to use only the tools that are defined in the SGML or XML standard and end up with a very substandard environment. The standards are powerful baselines for building environments but were never intended as detailed roadmaps for process support.

          We provide some descriptions of these concepts on our web site at
          http://www.xsystemsinc.com/prodpres/xml_apsum.htm


          Regards,

          Barry
        • jshelton@metasolv.com
          Odd, I thought that Tweddle Litho did most of the Ford manuals. They presented at this year s Single Sourcing conference in San Francisco. Jan Shelton ...
          Message 4 of 21 , Jun 6 9:09 AM
          • 0 Attachment
            Odd, I thought that Tweddle Litho did most of the Ford manuals. They
            presented at this year's Single Sourcing conference in San Francisco.

            Jan Shelton

            --- In xml-doc@y..., Barry A. Schaeffer <barry@X...> wrote:
            > We have run into two distinct challenges in the management of
            shared content:
            <snip>

            > We have been working with a concept called, in the aircraft
            industry, "effectivity" since 1995. Ford, for instance, keeps 12
            years of owners manuals live for each of its auto models. Through
            effectivity, since 1996, all versions of each manual are authored and
            managed from single SGML document file.
          • mark_nazimova@ibi.com
            ... If by context you mean the information s context (e.g., when describing a feature, the context might be for which of several products the feature is
            Message 5 of 21 , Jun 6 10:08 AM
            • 0 Attachment
              Michael Priestley writes:

              > That was one of the experiences that fed into the topic focus of
              > DITA: we wanted to separate content (the topics) from context (the
              > various ways in which the topics might be reused). That way you
              > could add new contexts (like a new book, or a new product, or a new
              > website, or a new helpset...) that reuse the topics without
              > affecting the actual topic content: your reuse scales, instead of
              > breaking at a certain level of complexity.

              If by "context" you mean the information's context (e.g., when
              describing a feature, the context might be for which of several
              products the feature is being described) and not just its
              presentation format (e.g. printed book or Web page), then how would
              you separate content from context? For example, when preparing to
              reuse a topic in a new context, wouldn't you sometimes need to edit
              required or conditional content (text, graphics, or links) in that
              topic to reflect the additional context?

              While I have your attention, is this an accurate (if overly brief)
              description of DITA: it encourages effective use of inheritance and
              specialization in designing schemas in general and information types
              in particular, reducing the work needed to create new elements and to
              maintain existing elements, and simplifying the DTD?

              Thanks,
              Mark Nazimova
              Mark_Nazimova@...
            • mpriestl@ca.ibm.com
              ... If you take the links out of the topic, and instead maintain a navigation map (a description of topic relationships) as part of the context, then you can
              Message 6 of 21 , Jun 6 10:36 AM
              • 0 Attachment
                I wrote:
                >> That was one of the experiences that fed into the topic focus of
                >> DITA: we wanted to separate content (the topics) from context (the
                >> various ways in which the topics might be reused). That way you
                >> could add new contexts (like a new book, or a new product, or a new
                >> website, or a new helpset...) that reuse the topics without
                >> affecting the actual topic content: your reuse scales, instead of
                >> breaking at a certain level of complexity.

                Mark Nazimova writes:

                >If by "context" you mean the information's context (e.g., when
                >describing a feature, the context might be for which of several
                >products the feature is being described) and not just its
                >presentation format (e.g. printed book or Web page), then how would
                >you separate content from context? For example, when preparing to
                >reuse a topic in a new context, wouldn't you sometimes need to edit
                >required or conditional content (text, graphics, or links) in that
                >topic to reflect the additional context?

                If you take the links out of the topic, and instead maintain a navigation
                map (a description of topic relationships) as part of the context, then you
                can apply whichever links are appropriate for a particular delivery context
                (like a product). DITA doesn't really go into detail about how to do this,
                but strategies like XLink external link libraries, RDF, or topic maps would
                seem appropriate. I've used a dirt-cheap method using XHTML and XSLT, the
                gist of which is described in "Managing web relationships with document
                structures", in Extreme 2000, or in the journal Markup Languages vol 2.
                issue 3.

                For text and graphics, there are things that can be done to minimize
                context dependency (like factoring out product-specific info into separate
                topics, and making sure screen caps only show the relevant part of the UI,
                not platform or product cues in the background). Even if you have some
                topics that are product- or context-specific, hopefully all the material
                that is common across contexts has been factored into reusable chunks, so
                there's no further processing required to reuse them.

                And that said, DITA does support attributes on just about every element for
                identifying audience, platform, product etc. - so in a pinch you can use
                those, though the more reuse you can achieve at the topic level the less
                you'll need to resort to element-level properties.

                >While I have your attention, is this an accurate (if overly brief)
                >description of DITA: it encourages effective use of inheritance and
                >specialization in designing schemas in general and information types
                >in particular, reducing the work needed to create new elements and to
                >maintain existing elements, and simplifying the DTD?

                That's accurate. I've been thinking of the architecture as affecting three
                primary domains:
                - content (which gets factored into topics and contexts)
                - design (which gets factored into DTD modules based on topic type and
                related to each other through spec attributes and entity includes)
                - process (which gets factored into XSLT modules based on topic type and
                spec attributes and related to each other through import cascades)

                So what you're describing is just the design part of it, but that is the
                part closest to my heart :-)

                >Thanks,
                >Mark Nazimova
                >Mark_Nazimova@...

                Thank you.

                Michael Priestley
                DITA Specialization Architect
                mpriestl@...
              • Dave Pawson
                At 06:36 PM 6/6/01, mpriestl@ca.ibm.com wrote: Michael, two points, neither serious. 1. The product needs a more memorable name than DITA. (or I need a
                Message 7 of 21 , Jun 6 11:22 AM
                • 0 Attachment
                  At 06:36 PM 6/6/01, mpriestl@... wrote:

                  <snip/>

                  Michael, two points, neither serious.

                  1. The product needs a more memorable name than DITA. (or I need a better memory ?)
                  2. You may as well abstract (as topics of course) some standard answers
                  since thats twice this question/answer has come up, for this list!
                  (then you could refer the list to the topic collection and links)

                  Regards DaveP
                • Roger L. Cauvin
                  One class of maintenance problems includes the duplication of original content within a document or documents. How about another class of maintenance
                  Message 8 of 21 , Jun 7 4:19 AM
                  • 0 Attachment
                    One class of maintenance problems includes the duplication of original
                    content within a document or documents. How about another class of
                    maintenance problems: content that already resides external to the
                    documents?

                    For example, let's say some software documentation needs to refer to the
                    build number of the current software release. Sometimes, this build number
                    already resides in a file external to the documentation. For each release,
                    developer tools automatically generate and record this build number. It is
                    a maintenance problem to manually (and redundantly) update the build number
                    in the software documentation for each release.

                    I can think of several places in which content external to documentation can
                    reside: files, databases, and web pages. In your experience, are there any
                    others? Also, are there other examples of kinds of external data that
                    present maintenance difficulties?

                    ---

                    Roger L. Cauvin
                    roger@...
                    http://lightning.prohosting.com/~rcauvin
                  • mpriestl@ca.ibm.com
                    ... memory ?) All the memorable names were taken (or memorable for the wrong reasons). ... You mean like:
                    Message 9 of 21 , Jun 7 1:28 PM
                    • 0 Attachment
                      Dave Pawson writes (unseriously):

                      >1. The product needs a more memorable name than DITA. (or I need a better
                      memory ?)

                      All the memorable names were taken (or memorable for the wrong reasons).

                      >2. You may as well abstract (as topics of course) some standard answers
                      > since thats twice this question/answer has come up, for this list!
                      > (then you could refer the list to the topic collection and links)

                      You mean like:
                      http://www-106.ibm.com/developerworks/library/x-dita3/

                      You would, of course, think that FAQs are the answer to everything :-)

                      With the caveat that the DITA FAQ doesn't exemplify the separation of
                      content from context - it's just a simple compound document of topics. (I
                      think it's a pretty natural progression to start by authoring a single-use
                      document that consists of multiple topics, and then migrate to a topic
                      repository plus context map when the information matures enough for reuse
                      to be an issue.)

                      Another caveat is that the comparison between DITA and DocBook needs to be
                      rewritten (I actually stand by most of what it says there, but one
                      paragraph isn't enough for me to justify the - fairly provocative -
                      statements I made).

                      Michael Priestley
                      DITA Specialization Architect
                      mpriestl@...
                    • HALL Bill
                      Barry Schaeffer s discussion of how to maintain duplicated data is excellent. At Tenix, we have used both of the approaches he details quite successfully, and
                      Message 10 of 21 , Jun 7 11:17 PM
                      • 0 Attachment
                        Barry Schaeffer's discussion of how to maintain duplicated data is
                        excellent. At Tenix, we have used both of the approaches he details quite
                        successfully, and have also thoroughly researched the third approach he
                        suggests avoiding. Tenix's experiences with all of these approaches may help
                        fill out Barry's comments

                        1. Reusable entities: It is worth noting that genuine standard texts (e.g.,
                        warnings, cautions, notes) as well as graphic objects can be managed as
                        reusable entities. The only tools you really need are nothing more than your
                        ordinary SGML/XML editor and an appropriately tweaked DTD. Shared texts are
                        held in an entity definition file called by the DTD and simply referenced
                        from the document instance as and when needed. In a heavy duty defense or
                        industrial documentation environment we do need the kinds of management
                        systems Barry described to keep track of the links and do "where used"
                        reports to manage the change process, but small documentation shops can
                        easily reuse entities without the added infrastructure costs at the slight
                        added cost of keeping track of things manually.

                        We have also been looking at what seems to be a very neat content solution
                        which extends the reusable entity approach into a complete management system
                        for small to moderate document databases: http://www.siberlogic.com/. Small
                        teams can implement at least parts of the system for free!

                        2. Applicability and effectivity: Applicability attributes relate the
                        element to a particular equipment configuration. Effectivity attributes
                        relate the element to a particular time or process change.

                        We implemented this approach in SGML to manage maintenance routines for the
                        class of 10 ANZAC frigates we are building for the Australian and New
                        Zealand navies.

                        a. Configuration applicability: One kind of applicability (in our DTD this
                        is a repeatable element at the document level) determines which
                        configuration item the routine relates to. The ships' maintenance management
                        system knows which configuration items occur on which ships, so in our case
                        the one routine - which may be applicable to several different
                        configurations - is applied to all (and only those) ships that have the
                        particular configuration item(s) specified in the configuration
                        applicability element. In one case this collapsed more than 50 separate
                        ship/configuration item specific routines into one class routine relating to
                        11+ different items on each of the four ships documented to that point.

                        b. Language applicability: Any structural element in the document may
                        include one to many "language" sub-elements (this is very easily defined
                        using inclusions as allowed in SGML but not in XML), where a language
                        attribute specifies whether the sub-element relates to an Australian or New
                        Zealand ship. In our case this was primarily used to cope with trivial
                        differences like part numbers relating to the different paint colours used
                        by the two clients, and all kinds of document and standing order references
                        which differed between the navies. However, the methodology would be equally
                        valid if we were addressing French vs English speaking clients. On delivery,
                        an extract process produced Australian and New Zealand fleet specific
                        documents.

                        c. Engineering change (EC) effectivity: All changes to maintenance routines
                        are managed within our engineering change process, and all aspects of the
                        routine are reviewed. For this reason we chose to determine effectivity of
                        the routine as a whole via an element at the document level. We could have
                        also done this at the level of individual elements exactly as described for
                        the language applicability. However, in our case it was more practical to
                        have the ships' maintenance management system determine from the EC element
                        when a given routine became valid on each particular ship.

                        The generic difficulty with all of these applicability and effectivity
                        techniques - where alternative elements are held in the one document, is
                        that the documents require significant delivery processing to determine
                        which elements are actually assembled into the required outputs. In turn,
                        this requires a reasonably sophisticated content management system to be
                        configured to do the element selections and/or the development of specific
                        processing scripts.

                        However, in our case, we had a large volume of documents that was labour
                        intensive to maintain and a client that was threatening to not accept
                        delivery of ships unless they were convinced we had solved content
                        management issues they had been complaining about for years. Each WEEK of
                        delayed acceptance would have cost us millions in liquidated damages. Here,
                        the methodology was highly cost effective. The approaches described above
                        solved the client's issues very successfully, and also radically reduced our
                        labour requirements to maintain the documents, which was enough by itself to
                        provide a return on investment by the end of the project. (Details of our
                        project are available in my paper published in the May 2001 issue of
                        Technical Communication, which I will forward electronically to those who
                        express an interest).

                        3. We are also seriously considering implementing the third (and generic)
                        kind of sharing, where any arbitrary element can be reused. The concept here
                        is to create a 'virtual' document for each deliverable which contains unique
                        content, but which can share redundant elements from wherever they were
                        first created - i.e., "write once, use many times". Barry Schaeffer lists
                        several valid reasons why this can be a challenging technology to implement.
                        The success of the solution will depend significantly on the capabilities of
                        the content management system used.

                        RMIT University's Structured Information Manager (see
                        http://www.simdb.com/), which we implemented for managing applicability and
                        effectivity in the ANZAC maintenance routines, offers the necessary
                        functions in the latest release of its Document Management System (DMS) to
                        identify reusable texts and to provide the necessary two-way management of
                        links. Document production from such a system is much more easily managed in
                        this approach as there is a 1:1 relationship between the virtual document as
                        held in the content management system and the release and version control
                        over the output deliverable produced for the document end user. However, as
                        Barry noted, managing changes against shared elements is a major issue that
                        must be appropriately implemented in any document change workflow process.

                        Given that our documentation development process for the ANZAC Ship Project
                        is essentially complete, from a commercial point of view we may decide not
                        to implement these extensions here. However, the capabilities are likely to
                        be highly valuable for new major projects where we are starting a whole new
                        body of documentation from scratch.

                        In a new project, we will probably implement all three of the major
                        approaches for eliminating duplicated data:

                        o Entities for shared elements that are managed independently from the flow
                        of a single document.

                        o Applicability and effectivity where it is desirable to maintain variants
                        (e.g., different "languages") in the one controlled document.

                        o Virtual documents using shared elements where it is desirable both to
                        maintain a 1:1 relationship between deliverables and the controlled
                        electronic copy and to eliminate the need to write shareable information
                        more than once (write once, use many times). The SIM content management
                        system will probably provide a practical level of support for identifying
                        potentially reusable elements.

                        Bill Hall
                        Documentation Systems Specialist
                        Data Quality
                        Quality Control and Commissioning
                        Tenix ANZAC Ship Project
                        Williamstown, Vic. 3016 AUSTRALIA
                        E-mail: bill.hall@... <mailto:bill.hall@...>
                        URL: http://www.tenix.com/
                      • Dave Pawson
                        ... Curious if you see xml include replacing the entity, as and when/if it gets application support. Better or the same as entities in this context? Regards
                        Message 11 of 21 , Jun 8 10:29 AM
                        • 0 Attachment
                          At 07:17 AM 6/8/01, HALL Bill wrote:

                          >1. Reusable entities: It is worth noting that genuine standard texts (e.g.,
                          >warnings, cautions, notes) as well as graphic objects can be managed as
                          >reusable entities. The only tools you really need are nothing more than your
                          >ordinary SGML/XML editor and an appropriately tweaked DTD. Shared texts are
                          >held in an entity definition file called by the DTD and simply referenced
                          >from the document instance as and when needed.


                          Curious if you see xml include replacing the entity, as and when/if
                          it gets application support.

                          Better or the same as entities in this context?

                          Regards DaveP
                        • alex@siberlogic.com
                          Roger, We at SiberLogic consider reuse to be the KEY problem in technical authoring. In many cases as much as 90% of the content can be reused across multiple
                          Message 12 of 21 , Jun 14 12:34 PM
                          • 0 Attachment
                            Roger,

                            We at SiberLogic consider reuse to be the KEY problem in technical
                            authoring. In many cases as much as 90% of the content can be reused
                            across multiple different documents describing similar, however not
                            identical products or product lines.

                            Our SiberSafe, an XML Content Management System, allows authors to
                            share and reuse XML content at the fragment-level across different
                            documents. With SiberSafe it is possible to automatically convert any
                            part of an existing XML document into an external reusable entity and
                            then include that entity into other documents.

                            SiberSafe keeps track of the relationships between reusable entities
                            and documents that reference those enities so that for every document
                            it is known what entities are referenced by what parts of that
                            document. For any reusable entity it is known what documents it is
                            referenced by.

                            SiberSafe automatically maintains a central Catalog of reusable
                            entities as new entities are created. From within the catalog it is
                            possible to see what reusable entities are available and what
                            documents they are used in.

                            SiberSafe also includes single-source publishing support based on
                            XSL/FO transformations. SiberSafe publishing features allow to
                            convert groups of XML DOCBOOK-compatible files into HTML, PDF and
                            other formats with a single mouse click. User-defined conversions are
                            supported for publishing files other than those based on DOCBOOK.

                            Though the commercial version of SiberSafe 2.0 is available at
                            www.siberlogic.com right away, the XML reuse and publishing
                            functionality features have been introduced only in SiberSafe 2.1 XML
                            Edition that is coming out next week, June 20, 2001 as a beta release.

                            SiberSafe 2.1 XML Edition will be offered at $550 per seat. We will
                            also be offering SiberSafe 2.1 XMetal Edition at $725 per seat (the
                            price includes both SiberSafe and XMetal).

                            Alex Povzner,
                            SIBERLOGIC INC
                            905-4742384
                            alex@...
                            www.siberlogic.com

                            --- In xml-doc@y..., "Roger L. Cauvin" <roger@c...> wrote:
                            > Technical writers: do you consider maintenance of your documents to
                            be a
                            > significant problem? I've worked closely with technical writers,
                            and have
                            > noticed that the documents they maintain often contain a great deal
                            of
                            > duplicate information. To some extent, writers can avoid the
                            duplication by
                            > providing links, but sometimes links are burdensome or
                            impractical. For
                            > example, software documentation may refer to the version number
                            many times.
                            > It would be both burdensome and impractical to provide a link to
                            the version
                            > number. Another example is terminology that changes as the software
                            > evolves.
                            >
                            > Does DocBook or do other XML technologies address this issue?
                            >
                            > ---
                            >
                            > Roger L. Cauvin
                            > roger@c...
                            > http://lightning.prohosting.com/~rcauvin
                          • Max Dunn
                            Hi Alex, This sounds cool. In terms of the XSL-FO, does it provide transformation from FO to PDF, or does it use an existing tool such as FOP? Thanks, Max
                            Message 13 of 21 , Jun 14 12:47 PM
                            • 0 Attachment
                              Hi Alex,

                              This sounds cool. In terms of the XSL-FO, does it provide transformation
                              from FO to PDF, or does it use an existing tool such as FOP?

                              Thanks,

                              Max
                              http://www.siliconpublishing.com/


                              -----Original Message-----
                              From: alex@... [mailto:alex@...]
                              Sent: Thursday, June 14, 2001 12:34 PM
                              To: xml-doc@yahoogroups.com
                              Subject: [xml-doc] Maintenance and Duplicaton Solutions (Re: Maintenance
                              and Duplication Problems)


                              Roger,

                              We at SiberLogic consider reuse to be the KEY problem in technical
                              authoring. In many cases as much as 90% of the content can be reused
                              across multiple different documents describing similar, however not
                              identical products or product lines.

                              Our SiberSafe, an XML Content Management System, allows authors to
                              share and reuse XML content at the fragment-level across different
                              documents. With SiberSafe it is possible to automatically convert any
                              part of an existing XML document into an external reusable entity and
                              then include that entity into other documents.

                              SiberSafe keeps track of the relationships between reusable entities
                              and documents that reference those enities so that for every document
                              it is known what entities are referenced by what parts of that
                              document. For any reusable entity it is known what documents it is
                              referenced by.

                              SiberSafe automatically maintains a central Catalog of reusable
                              entities as new entities are created. From within the catalog it is
                              possible to see what reusable entities are available and what
                              documents they are used in.

                              SiberSafe also includes single-source publishing support based on
                              XSL/FO transformations. SiberSafe publishing features allow to
                              convert groups of XML DOCBOOK-compatible files into HTML, PDF and
                              other formats with a single mouse click. User-defined conversions are
                              supported for publishing files other than those based on DOCBOOK.

                              Though the commercial version of SiberSafe 2.0 is available at
                              www.siberlogic.com right away, the XML reuse and publishing
                              functionality features have been introduced only in SiberSafe 2.1 XML
                              Edition that is coming out next week, June 20, 2001 as a beta release.

                              SiberSafe 2.1 XML Edition will be offered at $550 per seat. We will
                              also be offering SiberSafe 2.1 XMetal Edition at $725 per seat (the
                              price includes both SiberSafe and XMetal).

                              Alex Povzner,
                              SIBERLOGIC INC
                              905-4742384
                              alex@...
                              www.siberlogic.com
                            • alex@siberlogic.com
                              Hi Max, In terms of publishing, by default SiberSafe relies on XSLT/FOP for DOCBOOK/XML- PDF and DOCBOOK/XML- HTML conversions, however we do not limit our
                              Message 14 of 21 , Jun 14 2:26 PM
                              • 0 Attachment
                                Hi Max,

                                In terms of publishing, by default SiberSafe relies on XSLT/FOP for
                                DOCBOOK/XML->PDF and DOCBOOK/XML->HTML conversions, however we do not
                                limit our users' choice by that technology and those target formats:
                                new custom-defined transformations can be added to our system by
                                Value Added Resellers and/or Consultants.

                                SiberSafe supports Transformation API that allows SiberSafe to use
                                3rd party conversion products, including those not necessarily
                                related to XML.

                                Alex Povzner,
                                SIBERLOGIC INC
                                905-4742384
                                www.siberlogic.com
                                alex@...

                                --- In xml-doc@y..., "Max Dunn" <maxdunn@s...> wrote:
                                > Hi Alex,
                                >
                                > This sounds cool. In terms of the XSL-FO, does it provide
                                transformation
                                > from FO to PDF, or does it use an existing tool such as FOP?
                                >
                                > Thanks,
                                >
                                > Max
                                > http://www.siliconpublishing.com/
                                >
                                >
                                > -----Original Message-----
                                > From: alex@s... [mailto:alex@s...]
                                > Sent: Thursday, June 14, 2001 12:34 PM
                                > To: xml-doc@y...
                                > Subject: [xml-doc] Maintenance and Duplicaton Solutions (Re:
                                Maintenance
                                > and Duplication Problems)
                                >
                                >
                                > Roger,
                                >
                                > We at SiberLogic consider reuse to be the KEY problem in technical
                                > authoring. In many cases as much as 90% of the content can be
                                reused
                                > across multiple different documents describing similar, however not
                                > identical products or product lines.
                                >
                                > Our SiberSafe, an XML Content Management System, allows authors to
                                > share and reuse XML content at the fragment-level across different
                                > documents. With SiberSafe it is possible to automatically convert
                                any
                                > part of an existing XML document into an external reusable entity
                                and
                                > then include that entity into other documents.
                                >
                                > SiberSafe keeps track of the relationships between reusable entities
                                > and documents that reference those enities so that for every
                                document
                                > it is known what entities are referenced by what parts of that
                                > document. For any reusable entity it is known what documents it is
                                > referenced by.
                                >
                                > SiberSafe automatically maintains a central Catalog of reusable
                                > entities as new entities are created. From within the catalog it is
                                > possible to see what reusable entities are available and what
                                > documents they are used in.
                                >
                                > SiberSafe also includes single-source publishing support based on
                                > XSL/FO transformations. SiberSafe publishing features allow to
                                > convert groups of XML DOCBOOK-compatible files into HTML, PDF and
                                > other formats with a single mouse click. User-defined conversions
                                are
                                > supported for publishing files other than those based on DOCBOOK.
                                >
                                > Though the commercial version of SiberSafe 2.0 is available at
                                > www.siberlogic.com right away, the XML reuse and publishing
                                > functionality features have been introduced only in SiberSafe 2.1
                                XML
                                > Edition that is coming out next week, June 20, 2001 as a beta
                                release.
                                >
                                > SiberSafe 2.1 XML Edition will be offered at $550 per seat. We will
                                > also be offering SiberSafe 2.1 XMetal Edition at $725 per seat (the
                                > price includes both SiberSafe and XMetal).
                                >
                                > Alex Povzner,
                                > SIBERLOGIC INC
                                > 905-4742384
                                > alex@s...
                                > www.siberlogic.com
                              Your message has been successfully submitted and would be delivered to recipients shortly.