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

I don't have any disagreement with the goals you describe below, with perhaps one caveat: when you say the concept worked well for DITA 1.0, a lot of people disagreed with you :-) They wanted versions of the document types that didn't include the software domains, or supported learning and training elements, or allowed a stem sentence to introduce a list of steps, or allowed the ability to conref a range of steps in a task instead of just one at a time, or supported indirection of links so they could be redirected by reusers.

So each successive version of the standard has tried to meet those new requirements, without sacrificing the goal of having a common standard that tools can support with fallthrough for specializations.

Some of the enhancements went into their own document types - so if you want to use the learning and training elements, for example, you choose a different set of document types than if you want to just do technical communication. Others couldn't be achieved through specialization, so had to be achieved through changes to the core architecture.

But a DITA processor that handles only the basic DITA topic and DITA map artifacts should support, through specialization, all the content in all the document types, without content loss.

So with DITA 1.3, we're trying to provide an explicit starting point for simplified DITA specialization and content creation, that eliminates redundant functions that have built up over time, and is even easier to get started with and support than DITA 1.0.

My question is: given that we have users who need the full range of DITA 1.2 function, and other users who want a specific subset, what mechanism could the DITA TC consider for reconciling these demands?

I suggest you take a look at what we're proposing for a lightweight DITA starter set here:
https://wiki.oasis-open.org/dita/LimitedDitaProfile

The strawman proposal starts under the heading "Lightweight DITA".

If after reading that you still think that it would be unacceptable to provide both full and lightweight versions of the standard, but must pick one, let me know. But I think it would be useful for you to see how we're thinking about the issue currently.

Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



From:        "Rodolfo M. Raya" <rmraya@maxprograms.com>
To:        <dita@lists.oasis-open.org>,
Date:        09/11/2012 02:23 PM
Subject:        RE: [dita] Proposal: Allow <xref> within <shortdesc>
Sent by:        <dita@lists.oasis-open.org>




I’m saying that there should be one standard that is flexible enough to allow customizations that follow well established rules. That concept worked well for DITA 1.0, I don’t see why it would not work for future DITA versions as well.
 
The common goal should be to design a standard that tools could support even when users need to work with a customized version.
 
Design DITA in a way that a publishing engine, a CMS or a translation tool can handle despite any custom enhancement added by the user.
 
Two browsers may show the same HTML page with a different layout. The difference in layout should not matter if the content reaches the audience in its entirety.
 
It should also be possible to process a  DITA document with or without custom enhancements without the tool used for the task noticing the difference. We may see a difference in rendering, but there should be no content loss caused by customization.
 
If in addition to what is expressed above the DITA standard can be noticeably simplified and still offer something that is useable off the shelf without requiring customization, then it would be a great improvement.
 
Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com
 
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Michael Priestley
Sent:
Tuesday, September 11, 2012 2:52 PM
To:
Rodolfo M. Raya
Cc:
dita@lists.oasis-open.org
Subject:
RE: [dita] Proposal: Allow <xref> within <shortdesc>

 
So you accept that there can be differences between DITA implementations. But you feel that only one of those variations should be included in the standard.

Is this correct?


Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist

mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



From:        
"Rodolfo M. Raya" <rmraya@maxprograms.com>
To:        
Michael Priestley/Toronto/IBM@IBMCA,
Cc:        
<dita@lists.oasis-open.org>
Date:        
09/11/2012 01:46 PM
Subject:        
RE: [dita] Proposal: Allow <xref> within <shortdesc>





Hi,

 
Please see my new comments below.

 
Regards,

Rodolfo

--
Rodolfo M. Raya      
rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com
 
From:
dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Michael Priestley
Sent:
Tuesday, September 11, 2012 2:01 PM
To:
Rodolfo M. Raya
Cc:
dita@lists.oasis-open.org
Subject:
RE: [dita] Proposal: Allow <xref> within <shortdesc>

 

Hi Rodolfo,


Would you still feel this way even if there were two completely different standards? EG: DITA for Rodolfo, and DITA for Specializers?


RMR: this would be as ridiculous as having two different HTML standards, one for Michael and one for browser developers. We need just one DITA standard.


If that would be acceptable, what is it about combining them into one standard - with two deliverables - that makes the whole unacceptable?


RMR: as said above, we need just one DITA to start with. Those that have special needs can extend, specialize, customize or whatever by following clearly established rules that allow tools to work with plain DITA and customized DITA without interoperability problems.

 


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