RE: [dita-adoption] Thoughts on DITA 1.2 adoption

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

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 
> 
>