[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA Task model
Andrej, You refer to your June 2008 exchange with Michael at http://tinyurl.com/ycz87lt, where you summarized your proposal thus: >... a definitive subset of DITA, let's call >it for argument's sake EDEN (Electronic Documentumentation Essential >Norm) .... EDEN would be a completely >valid DITA form but would not allow the following constructs: > >1) Recursive elements - no recursion >2) Block spanning elements - only inline elements allowed within block >elements >3) Conrefs - replaced by xrefs for linguistically complete phrases or >sentences >4) Specialization past the basic Topic, Concept, Task and Reference - no >specialization I'll remind the BusDocs team of this for its relevance to the proposal under review there. /Bruce > -----Original Message----- > From: Andrzej Zydron [mailto:azydron@xml-intl.com] > Sent: Thursday, September 24, 2009 10:08 AM > To: rockley@rockley.com > Cc: 'Joann Hackos'; 'DITA TC' > Subject: Re: [dita] DITA Task model > > Hi Everyone, > > This is also another good argument for DITA EDEN (Electronic > Documentation Essential Norm) which is a core 100% compatible > subset of DITA for normal human beings that do not go around > with propellers on their heads but want a simple, usable DITA model. > > Best Regards, > > AZ > > Ann Rockley wrote: > > > > I agree completely with these statements. One of the > primary focus' of > > DITA is reuse and sharing. If we can't share reusable content it > > negates the value of the standard. If we expect > organizations to have > > an expert in XML to implement DITA we have lost them. One > out of 10 of > > the organizations we work with might possibly have someone who > > understands XML, most do not. > > > > This is only the tip of the iceberg. If we go towards > enterprise use > > of DITA which could mean sharing of content between Tech Docs, > > Training, Marketing, Customer Support or more it will never > become a > > realization if they cannot share. > > > > We are in fact creating silos again. And at minimum, we are moving > > towards a situation where an organization has to constantly > > re-engineer their content if they want to adopt the latest standard > > and still continue to access their existing content. > > > > I am equally concerned. It has also raised a lot of flags > in the work > > we are doing in BusDocs. > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:* Joann Hackos [mailto:joann.hackos@comtech-serv.com] > > *Sent:* Thursday, September 24, 2009 9:38 AM > > *To:* DITA TC > > *Subject:* [dita] DITA Task model > > > > When was it decided that the original task model in DITA > 1.1 would be > > rewritten as a constraint of the general task model? I don't recall > > hearing any discussion of the impacts of such a rewrite. Instead of > > being a specialization of topic, task is now a constraint > of general > > task. Why was this decision made and did anyone consider the > > implications of the change from a specialization to a constraint? > > > > What is the full impact of the decision by someone by > rewrite task? Is > > task in DITA 1.2 full compatible with task in DITA 1.1? > Will conrefs > > written in DITA 1.1 task function properly in DITA 1.2 > task? I really > > would like an answer to the constraint decisions. > > > > Machinery task is also written as a constraint of the DITA > 1.2 general > > task. Is it also incompatible with either general or strict task? > > > > It appears that this means that an organization in which content is > > shared among tasks must be extremely careful that only one > task model > > is used. Is that a correct assumption? Is DITA 1.2 task backward > > compatible with DITA 1.1 task? > > > > I don't think we can take this at all lightly. Despite Eliot's > > argument that you have to be an XML expert programmer to implement > > DITA, that is not the reality in the user community. How will we > > possibly communicate the enormous problems that will result > if conrefs > > no longer work? As the co-chair of the Adoption TC, I don't > even know > > where to begin. > > > > The Arbortext decision to call general task "task" has > revealed this > > problem, which was actually quite fortuitous. Considering their > > decision, was anyone from PTC aware of the problems that > were going to > > occur if adopters begin using more than one task model. The > situation > > in Arbortext Editor 5.4 is untenable, at least for all of my > > community. As I understand it, if authors use task quite > innocently in > > 5.4 Out of the Box, they will invalidate all their conrefs already > > developed in DITA 1.1. That's a truly critical problem. > > > > To repeat, conrefs do not work between general task and > task. Do they > > work between task 1.1 (specialization) and task 1.2 > (constraint)? Or > > between machinery task and other tasks? > > > > I lost sleep last night stewing over this. It may cause > more problems > > among adopters than we will be able to handle. > > > > JoAnn > > > > -- > email - azydron@xml-intl.com > smail - c/o Mr. A.Zydron > PO Box 2167 > Gerrards Cross > Bucks SL9 8XF > United Kingdom > Mobile +(44) 7966 477 181 > FAX +(44) 1753 480 465 > www - http://www.xml-intl.com > > This message contains confidential information and is > intended only for the individual named. If you are not the > named addressee you may not disseminate, distribute or copy > this e-mail. Please notify the sender immediately by e-mail > if you have received this e-mail by mistake and delete this > e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, > lost, destroyed, arrive late or incomplete, or contain > viruses. The sender therefore does not accept liability for > any errors or omissions in the contents of this message which > arise as a result of e-mail transmission. If verification is > required please request a hard-copy version. Unless > explicitly stated otherwise this message is provided for > informational purposes only and should not be construed as a > solicitation or offer. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]