[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-adoption] Thoughts on DITA 1.2 adoption
Why don't we just refer vendors to the list that's already there and ask them to state, in their release notes or some other place that's accessible to this TC, which features they have implemented. I don't think we can come up with a "these are the features you're expected to support in order to claim DITA 1.2 compliance" without us getting into the compliance-enforcement discussion again. I would rather focus our efforts on working on the user evaluation list and test cases (which I hope to have time to do in the near future) than start up on the compliance thread again. Vendors will continue to claim DITA 1.2 support ahead of any true support, because that's the way many vendors are. Also, those that do support 1.2 may only support a subset for some time (or for ever) and it's up to the users to assess competitive products they use or are considering using. Cheers, Gershon -----Original Message----- From: Bruce Nevin (bnevin) Sent: Tuesday, August 03, 2010 7:22 PM To: Grosso, Paul; DITA Adoption TC Subject: RE: [dita-adoption] Thoughts on DITA 1.2 adoption Is the concern interoperability across vendors? Advocating a minimum set of features sufficient to ensure interoperability? I haven't thought about dependencies among features such that if you fail to support feature A then Feature B is in trouble. If that's an issue (I don't *think* so), it should go in this paper. But insofar as 1.2 is backward compatible with 1.1, then a vendor that fails to support 1.2 at all can still handle 1.2 content in a 1.1 environment; and it follows that a vendor that supports a subset of 1.2 can handle content from a vendor that supports 1.2 completely. That's where the logic takes me. Does that fit with facts? As Paul says, vendors think about what they want to do first. Complexity and cost can tip this calculation differently for different vendors, and that's a factor that we can't address. If cross-vendor compatibility isn't the issue, there might be other reasons to recommend a minimal or initial set of features to implement. /B > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Tuesday, August 03, 2010 11:12 AM > To: DITA Adoption TC > Subject: RE: [dita-adoption] Thoughts on DITA 1.2 adoption > > > > > -----Original Message----- > > From: Joann Hackos [mailto:joann.hackos@comtech-serv.com] > > Sent: Tuesday, 2010 August 03 9:41 > > To: Bruce Nevin (bnevin); DITA Adoption TC > > Subject: Re: [dita-adoption] Thoughts on DITA 1.2 adoption > > > > We actually have the TC original list (in user-friendly form) at > > http://wiki.oasis-open.org/dita-adoption/Dita12changes > > > > What I'm looking for is a list of features that should be > adopted by > > editor and CMS vendors. > > > > Paul asks what features should not be adopted, but even Arbortext > > appears to have decided not to support certain 1.2 > features, at least > > not initially. > > We'd like to know what each vendor is or is not implementing. > > Yes, implementors often have less than infinite time and > resources and therefore do have to decide what to implement > first. I'm not aware of Arbortext saying that there are some > features we never plan to implement. > > But asking vendors for a list of features they have or plan > to implement is different from this TC coming up with "a list > of features that should be adopted by editor and CMS vendors" > (as you repeat above). > > Regarding "a list of features that should be adopted by > editor and CMS vendors", my previous question remains. > > Regarding "asking vendors for a list of features...", I'm not > sure that is in the purview of this TC. > > paul > > > > > JoAnn > > > > > > On 8/2/10 12:23 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: > > > > > For some time the problem was that there was no > definitive list of > > > discrete, identified DITA 1.2 features. This may still be > the case. > > When > > > I was looking for "the list of features" last year I > combed through > > > email threads etc. and sent a draft list to JoAnn. > > > > > >> -----Original Message----- > > >> From: Grosso, Paul [mailto:pgrosso@ptc.com] > > >> Sent: Monday, August 02, 2010 10:55 AM > > >> To: Joann Hackos; DITA Adoption TC > > >> Subject: RE: [dita-adoption] Thoughts on DITA 1.2 adoption > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Joann Hackos [mailto:joann.hackos@comtech-serv.com] > > >>> Sent: Monday, 2010 August 02 9:14 > > >>> To: DITA Adoption TC > > >>> Subject: [dita-adoption] Thoughts on DITA 1.2 adoption > > >>> > > >>> Hi All! > > >>> At today's meeting could we discuss developing a basic list of > DITA > > >> 1.2 > > >>> features that we would like to see adopted by editing > and content > > >>> management developers? > > >> > > >> I'm not sure I understand. > > >> > > >> Which features do we NOT want to see adopted by editing > and content > > >> management developers? > > >> > > >> paul > > >> > > >>> > > >>> In asking about DITA 1.2 adoption in writing the status > > >> article, I got > > >>> such diverse feedback from developers that I would like > to have a > > >>> standard list. > > >>> > > >>> Specializations > > >>> Learning and Training > > >>> Safety Hazard > > >>> Machine Industry > > >>> > > >>> Keyref > > >>> Conkeyref > > >>> Conref Push > > >>> Delayed conref resolution > > >>> > > >>> Referencing a range of elements > > >>> > > >>> Constraint mechanism > > >>> Controlled values > > >>> Taxonomy mechanism > > >>> Acronym/glossary > > >>> > > >>> New linking capabilities in relationship tables > > >>> > > >>> All the new DTD capabilities such as <sectiondiv> <bodydiv> New > > >>> map references > > >>> > > >>> I'd like to set something up that is like a checklist that > > >> vendors can > > >>> go to and tell everyone what they have implemented (or the > > >> dates for > > >>> implementation). > > >>> > > >>> JoAnn > > >> > > >> > -------------------------------------------------------------------- > > - > > >> 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_workgr > > >> oups.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 > > > --------------------------------------------------------------------- > 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_workgr oups.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]