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] My increasing concerns about LwDITA and template-based specialization


Note that the question is not whether or not template-based specialization is useful—it almost certainly is.

 

The question is whether or not a particular template-based specialization approach should be part of the Lightweight DITA *standard*.

 

A working template-based specialization mechanism will be useful whether or not it is standardized. Standardizing it as part of the LW Dita effort is not necessary and would add significant cost and overhead to the LW Dita standardization process.

 

Cheers,

 

E.

 

--

Eliot Kimber

http://contrext.com

 

 

 

From: Noz Urbina <noz.urbina@urbinaconsulting.com>
Date: Monday, January 23, 2017 at 2:24 PM
To: Michael Priestley <mpriestl@ca.ibm.com>, Eliot Kimber <ekimber@contrext.com>
Cc: DITA TC <dita@lists.oasis-open.org>
Subject: Re: [dita] My increasing concerns about LwDITA and template-based specialization

 

+1 to Michael's comments.

I have been asking for Templates-based attribute specialisation for years.

 

On Mon, 23 Jan 2017, 17:54 Michael Priestley, <mpriestl@ca.ibm.com> wrote:

Hi Eliot,

They are currently defined as conforming specializations. There is absolutely no need to add anything to the base DITA vocabulary.

It is true that these are specializations with an audience type other than plain author - someone who is doing content typing for a project, but not technical enough to want to dive deep into XML schema definition using XSD or RNG. That responsibility might be in the hands of the content strategist, or of the content engineer, depending on where the lines get drawn on technical skills/proficiency.

In my experience working on marketing projects (one of the target domains for Lightweight DITA) I've seen content type definition happen every time - they are rarely taking what's available out of the box, but instead defining fields/structure as required for a particular set of use cases.

I don't anticipate everyone needing or wanting to use the Lightweight DITA template-based specialization process, but I also think it's important to recognize the needs of the content strategy role on a content project, just as we recognize other authoring roles and requirements besides primary author (SME authoring requirements, for example, or reviewer requirements, or information architect requirements...)

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com




From:        Eliot Kimber <ekimber@contrext.com>
To:        DITA TC <dita@lists.oasis-open.org>
Date:        01/23/2017 12:16 PM
Subject:        Re: [dita] My increasing concerns about LwDITA and template-based specialization
Sent by:        <dita@lists.oasis-open.org>





Just because there are multiple potential uses for the markup that would also drive template-based specialization generation, it does not, by itself, motivate or justify standardization as part of the core DITA architecture.
 
That is, all of these use cases are still outside the scope of DITA *content*, the stuff that authors write and capture as conforming DITA documents.
 
If a body of practice and tools around template-based processing develops that is sufficiently well adopted that it is worth standardizing then that can be done separately from the core DITA architecture—there is no aspect of template-based tooling that requires anything within the domain of *content* as authored.
 
For example, all new attributes and markup needed to augment otherwise-normal DITA maps and topics to support specialization generation or output processing could be put in namespaces, putting them explicitly outside the scope of normal DITA markup. Or they could be defined as conforming specializations using @base, <data>, and other general-purpose elements, if that made more sense for some reason (which it might). And of course you can park a fleet of trucks in @outputclass.
 
Thus there’s no need to add anything to the base DITA vocabulary in order to support this type of tooling, certainly not as a prerequisite for developing such tools and proving their designs and usefulness.
 
Likewise, the existence of these tools is not a prerequisite for the use or adoption of a Lightweight DITA. Having such tools will definitely be useful and to everyone’s advantage, but they are not a prerequisite. If experience is any guide, the vast majority of users will want something pre-defined that they can just pick up and use, which means that having a well-thought-out subset of DITA 1.3 markup is the most important thing and that by itself is hard enough.
 
Cheers,
 
Eliot
 
--
Eliot Kimber
http://contrext.com
 
 
 
From: <dita@lists.oasis-open.org> on behalf of Michael Priestley <mpriestl@ca.ibm.com>
Date:
Saturday, January 21, 2017 at 9:33 PM
To:
Kristen James Eberlein <kris@eberleinconsulting.com>
Cc:
DITA TC <dita@lists.oasis-open.org>
Subject:
Re: [dita] My increasing concerns about LwDITA and template-based specialization

 
Hi Kris,

Here's my perspective:


>I'm not sure that adding new attributes and elements in the spec in
>order to drive tool development is an appropriate thing to do.


I think as long as the markup is semantic, this is not only appropriate but normal. You could argue that every element and attribute in full DITA was added to drive tool development, in the sense that none of that markup had any meaning or effect until it was turned into some kind of output by a tool. There are many examples of elements and attributes supporting specific tooling requirements, from the filtering attributes in DITA 1.0 to the assessment elements in the learning and training specialization.


>I think it would 100% appropriate if someone wants to build and sell an
>application, and include with the application directions on how to
>create an annotated XML file that can processed to get a monolithic DTD.
>Or have an Open Source project which produces a plug-in that oXygen will
>bundle with their application.


And if they use specialized elements and attributes to do that annotation, then their annotations will not be portable across template generation tools. It really will be bound to one tool, instead of being a standard. This is perfectly appropriate, of course, but it's a different use case than having a standard that allows multiple tools to coexist and work on the same content set.


>However, I truly don't see an argument for adding new elements and
>attributes to the specification in order to develop one-time artifacts
>(the templates) that can be fed into tooling to autogenerate DTDs


Maybe this is where our different interpretations start. I don't see these as one-time artifacts. Over time the goal is to have the same annotated template support multiple outputs, many of which could require ongoing updates and maintenance:


- the documentation (update to address the requirements of new users, or just improve based on existing usage problems)
- stylesheet overrides (for example to generate section titles - update to address changing editorial rules/requirements)
- authoring templates (as with documentation, update to address requirements of new users etc.)


In addition to those use cases, there is the (re)use of the template by other designs - the goal is to allow reuse of specialized elements through conref between templates, which will be simpler and more direct for users to work with and understand compared to our current full DITA modularization with multiple entity overrides.


I don't know if this helps to convince you, but I hope that I've addressed some of the concerns you've identified here.


Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com




From:        
Kristen James Eberlein <kris@eberleinconsulting.com>
To:        
DITA TC <dita@lists.oasis-open.org>
Date:        
01/19/2017 08:15 AM
Subject:        
[dita] My increasing concerns about LwDITA and template-based specialization
Sent by:        
<dita@lists.oasis-open.org>






I think we all would like to specialization easier to do. But ...

I'm not sure that adding new attributes and elements in the spec in
order to drive tool development is an appropriate thing to do.

I think it would 100% appropriate if someone wants to build and sell an
application, and include with the application directions on how to
create an annotated XML file that can processed to get a monolithic DTD.
Or have an Open Source project which produces a plug-in that oXygen will
bundle with their application.

However, I truly don't see an argument for adding new elements and
attributes to the specification in order to develop one-time artifacts
(the templates) that can be fed into tooling to autogenerate DTDs

I'm going to need a whole lot more convincing. It just seems wrong.


--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting

www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)


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








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