RE: [dita-adoption] DITA 1.2 compliant CMS

["Grosso, Paul" <pgrosso@ptc.com>]

> -----Original Message-----
> From: Gershon Joseph (gerjosep) [mailto:gerjosep@cisco.com]
> Sent: Sunday, 2010 September 12 8:06
> To: Joann Hackos; Grosso, Paul; DITA Adoption TC
> Cc: Nitchie, Chris
> Subject: RE: [dita-adoption] DITA 1.2 compliant CMS
> 
> OK, I'll develop the article. I've added the following entries to the
> DITA articles page at http://wiki.oasis-open.org/dita-
> adoption/SignUp#OtherFeatureArticles:
> *  What to look for in a DITA-aware CMS
> *  Evaluating DITA Tools
> 
> I have completed a first draft of the latter, and just need to do a
> full proof-read through it and get the white paper PDF kit from Hal so
> I can publish it.

I assume by "publish it" you mean produce a draft for the TC
to review.  All I've seen so far on this topic is the "Factsheet"
page on which I made many comments long ago to which there has
never been any response, so we certainly aren't any where near
ready to "publish" anything on this topic yet.

paul

> 
> Cheers,
> Gershon
> 
> 
> -----Original Message-----
> From: Joann Hackos [mailto:joann.hackos@comtech-serv.com]
> Sent: Sunday, September 12, 2010 2:47 PM
> To: Gershon Joseph (gerjosep); Paul Grosso; DITA Adoption TC
> Cc: Nitchie, Chris
> Subject: Re: [dita-adoption] DITA 1.2 compliant CMS
> 
> Hi Gershon,
> I'd definitely like to see a separate article. It would clear up the
> problem
> we're seeing with some entries into the DITA CMS environment. We're
> being
> told that document management systems can handle DITA files, as Paul
> suggests. All we get is a dumb storage facility that provides none of
> the
> critical functional that makes handling DITA so much more efficient and
> effective.
> 
> I certainly do not want to rely on the editor to do all the work. That
> puts
> the editor in between me and the functionality I need. It also means
> that I
> am locked into one editor since all my DITA-specific content is being
> managed by the editor. Certainly, we've seen some valiant attempts by
> editors, such as Xmetal, to provide functionality in a product like
> SharePoint, which is completely unsuitable for handling DITA content.
> Xmetal
> makes it possible but not pleasant.
> 
> It's not Microsoft, in my view, that is pushing SharePoint for DITA but
> IT
> professionals who already own SharePoint and are ignorant of its
> limitations
> or with the requirements for a strong DITA CMS environment. It's the
> same
> with Documentum and some other systems that are not designed to support
> XML.
> 
> JoAnn
> 
> 
> On 9/12/10 5:35 AM, "Gershon Joseph" <gerjosep@cisco.com> wrote:
> 
> > Agreed. A CCMS *understands* the underlying XML and can operate on
> it, or at a
> > minimum run queries on it. Also, a DITA-aware CMS prevents users from
> deleting
> > an object that's the target of any DITA link, be it conref, xref, or
> any of
> > the other linking mechanisms. This last point is where most CMSs fail
> dismally
> > in my opinion.
> >
> > Another important point for me, which I allude to above, is the
> ability to
> > understand the content. For example, most CMSs today parse the XML
> files at
> > check-in time to extract metadata from the XML content into the CMS
> metadata
> > level. To me this is plain stupid, duplicating the single source of
> truth we
> > already have and maintain in the XML files. Now we have two sources
> of truth
> > -- the raw XML source and the CMS metadata. There are some CMSs that
> allow
> > users to update the metadata in the CMS, but fail to propagate those
> changes
> > to the XML files. Also, you need to code the CMS to extract each
> piece of XML
> > information you want to leverage, which is a step you don't need with
> a CMS
> > that understands the raw DITA markup. If I want to search on all
> topics that
> > reference a particular audience level, I expect the CMS to perform
> that search
> > on the XML content; however, many CMSs require me to first extract
> that as
> > metadata (a procedure that requires customization and development)
> and only
> > then is it available for search; otherwise all I have is a full text
> search,
> > since the XML files are treated as plain text. I want to be able to
> search for
> > a specific audience in a specific topic type (e.g. task topics only)
> and only
> > on specific element types (e.g. syntaxdiagram). I can't do this type
> of search
> > at all unless the CMS is truly DITA-aware.
> >
> > I could go on, but perhaps email is not the best medium for this. I
> could add
> > a section on why a CMS should be DITA aware and what we expect a
> DITA-aware
> > CMS to do in my check list article, or I could develop a separate
> article. I
> > think the latter may be more useful. What do others on the TC think?
> >
> > Cheers,
> > Gershon
> >
> > -----Original Message-----
> > From: Joann Hackos [mailto:joann.hackos@comtech-serv.com]
> > Sent: Saturday, September 11, 2010 10:11 PM
> > To: Paul Grosso; DITA Adoption TC; Gershon Joseph (gerjosep)
> > Cc: Nitchie, Chris
> > Subject: Re: [dita-adoption] DITA 1.2 compliant CMS
> >
> > Actually, we expect the CMS to handle all manner of DITA functions
> without
> > needing an editor. In fact, we want to be able to validate links,
> initiate
> > publishing, initiate translation, check "where used", manage a
> workflow, and
> > more solely within the CMS. In several CCMSs, we can set up all the
> > conditional publishing options, with more options than we have to
> handle
> > them than in the Open Toolkit, and we can execute conditional
> publishing,
> > all without reference to the authoring tool.
> >
> > We don't want to require that someone use an authoring tool to handle
> all
> > processes, with or without the OT. I want visibility into the XML
> objects
> > through the CMS. I want to be able to affect the content without an
> editor.
> > I can write scripts that change a tagging error throughout a portion
> of the
> > database. I can open a single element in a DITA topic and edit it
> without
> > opening the entire topic.
> >
> > Perhaps part of the problem is that using an XML aware CMS is quite
> > different from using something like Documentum, which is architected
> to
> > handle files as BLOBS rather than XML objects. A component CCMS does
> a great
> > deal more than just store. It's an active aid to good information
> management
> > in XML and in DITA.
> >
> > JoAnn
> >
> >
> > On 9/9/10 4:29 PM, "Paul Grosso" <pgrosso@ptc.com> wrote:
> >
> >> I'm not so much asking what DITA compliance means (though
> >> that's a tricky enough question), I'm asking what it means
> >> for a CMS to be DITA compliant.
> >>
> >> In short, what does a CMS do--above and beyond what the
> >> authoring/composition tool that is used to work with the
> >> content stored in the CMS does--that could be DITA aware?
> >>
> >> I fail to understand what it would mean for a CMS to
> >> support keyref.  I do not pretend to understand CMS
> >> systems very well, so I may be off base here (and I'd
> >> be happy to be corrected), but I didn't think it was up to
> >> data bases to resolve references that the editor/composition
> >> system is going to resolve.
> >>
> >> I am really over my head here--CMS systems are not at all
> >> in my areas of expertise, so perhaps there are many people
> >> out there who will know what it means (or should mean) for
> >> a CMS to be compliant to DITA 1.2, but perhaps there are
> >> also many like me who don't know, so it would only make
> >> sense if we could explain what it might mean.
> >>
> >> Do we have any members of this TC who are--or who have
> >> clients who are--asking for certain DITA-aware features
> >> from a CMS that go beyond what the editor/composition
> >> system handles for you, and if so, what features are they?
> >>
> >> paul
> >>
> >>> -----Original Message-----
> >>> From: Joann Hackos [mailto:joann.hackos@comtech-serv.com]
> >>> Sent: Thursday, 2010 September 09 17:01
> >>> To: Grosso, Paul; DITA Adoption TC
> >>> Cc: Nitchie, Chris
> >>> Subject: Re: [dita-adoption] DITA 1.2 compliant CMS
> >>>
> >>> In all of my recent discussions with CMS vendors, I've asked about
> >>> support
> >>> for DITA 1.2. The answer I've most frequently received is "We're
> >>> studying
> >>> the spec and deciding what we can and will implement." We have been
> >>> told
> >>> that a particular CMS, for example, will not have support for
> keyref
> >> in
> >>> the
> >>> immediate future. Or, that there will not be support for all or
> >> several
> >>> of
> >>> the 1.2 features. Quite clearly, there is work that CMS vendors
> must
> >> do
> >>> to
> >>> conform to the new 1.2 features that is not simple or obvious.
> >>>
> >>> We continue to find CMS vendors who claim to be DITA compliant but
> who
> >>> do
> >>> not support even the most basic functionality. All they do,
> >> apparently,
> >>> is
> >>> import and export DITA files. Nothing happens between the ears.
> Yet,
> >>> they
> >>> are selling their products as DITA ready.
> >>>
> >>> So what does DITA compliant then mean? We are, of course, working
> on
> >>> this
> >>> issue in the TC. Companies ask us how they can write their RFPs so
> >>> ensure
> >>> that they're not being fooled about DITA support in the CMS.
> >>>
> >>> Is that what we intend by compliance? I think compliance is a much
> >> more
> >>> legalistic term but we do mean that something must be in place to
> >>> support
> >>> DITA satisfactorily.
> >>>
> >>> JoAnn
> >>>
> >>>
> >>> On 9/9/10 9:33 AM, "Paul Grosso" <pgrosso@ptc.com> wrote:
> >>>
> >>>> Reading our DITA 1.2 Status article at
> >>>> http://www.oasis-
> >>> open.org/committees/download.php/38956/DITA12SpecStatus
> >>>> Update.pdf
> >>>> someone has seen the comment in the second para of the
> >>>> "DITA 1.2 Readiness for Use" section that says that
> >>>> certain CMS vendors have announced upcoming DITA 1.2
> >>>> support and the comment near the bottom of the article
> >>>> urging CMS vendors to move quickly to support DITA 1.2
> >>>> and raised the question of what it means for a CMS to be
> >>>> DITA compliant (much less support DITA 1.2 in particular).
> >>>>
> >>>> I have to admit I didn't think much about these statements
> >>>> when I reviewed this article.  I don't think about CMS's
> >>>> much at all.  They are just data bases to me, and the
> >>>> ability to work with DITA in particular or XML in general
> >>>> rarely has anything to do with the data base, it has to
> >>>> do with the application that knows how to put things into
> >>>> the data base and take it out of the data base.  In our
> >>>> case, that's the Arbortext Editor and CMS adapter front end.
> >>>>
> >>>> In fact, on our "Fact Sheet" wiki page at
> >>>> http://wiki.oasis-open.org/dita-adoption/factSheet
> >>>> in the "Support for management of topics within a repository"
> >>>> section I long ago questioned the CMS section there, but we
> >>>> have never discussed my issues with that page.
> >>>>
> >>>> So I'm back to asking what it might mean for a CMS
> >>>> to be DITA 1.2 compliant.
> >>>>
> >>>> paul
> >>>>
> >>>>
> >>>>
> >> --------------------------------------------------------------------
> -
> >>>> To unsubscribe from this mail list, you must leave the OASIS TC
> that
> >>>> generates this mail.  Follow this link to all your TCs in OASIS
> at:
> >>>> https://www.oasis-
> >>> open.org/apps/org/workgroup/portal/my_workgroups.php
> >>>>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail.  Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >