[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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 >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]