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] Proposal: Allow <xref> within <shortdesc>


Hi,

 

Please see my comments below prefixed with RMR.

 

Regards,

Rodolfo

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com

 

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, September 11, 2012 12:27 PM
To: Rodolfo M. Raya
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Proposal: Allow <xref> within <shortdesc>

 

Hi Rodolfo,

Keep in mind that for DITA 1.3 there will be an extremely simplified set of doctypes available for people who want to start with the minimum. We also provided a minimal doctype in DITA 1.2, but for topic only, and that doesn't seem to be getting much attention or use.

RMR: there should be only one set of deliverables, not many to choose from. Adding multiple sets increases complexity for the first time user and would probably scare some potential users.

 

RMR: I would not choose to work with DITA 1.3 if I have to pick an XML standard for structured authoring that allows content reuse.

 


Generally speaking, the audience of the spec includes both specializers and authors, and most of the doctypes you see in DITA are constrained, and don't represent every possible option to the end user. A good example is the task type in DITA 1.2, which has a general version that can be used by specializers or authors requiring more flexibility, as well as a constrained version for use by most authors directly.

RMR: Two versions of Task is extra complication and a good example of the mess created. A well designed Task should have been enough.


So when you say the standard is getting more complex every day, I need to understand which behaviors are triggering that reaction, since there are lots of different motivations on the TC.

- when we add two versions of a task, explicitly to accomodate direct users as well as specializers, are we making the standard too complex? We did it in an attempt to simplify things for end-users, but maybe we just made things worse?

 

RMR: Yes, you complicated the standard unnecesarily. Things were made worse. As I said before, a well-designed Task should have been enough.


- when we add more conref options, like range or push, for use directly by end-users, we're certainly making the standard more complex - but it's not because of a focus on specializers or implementers, it's directly in response to requests from advanced users. Which is where the simplified doctypes we're targetting for 1.3 come in, as an alternative for starter users or occasional authors.

RMR: adding more content referencing options increased complexity and did not provide great benefits to most existing users. Without conref push and keys, the old DITA was easier to implement and support. I don’t have actual statistics, but from what I’ve seen keyref was not adopted by the majority of DITA users. To me, it seems that complexity was increased for all to benefit just a few.

 


In the example that triggered this discussion, does it really increase complexity for end-users if we let xref be authored directly in shortdesc, instead of making authors sneak it in wrapped in a ph? Making content models more consistent usuaally decreases complexity, rather than increases it, doesn't it? Unless there are really good reasons for guiding people down different paths with the different models, which I don't think is the case anymore on this issue.

 

RMR: I don’t care about adding <xref> to <shotdesc>. I reacted to a statement that clearly described that DITA is not being designed for authors but for specializers and implementers instead.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]