OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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