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
- From: "Michael Priestley" <mpriestl@ca.ibm.com>
- To: Eliot Kimber <ekimber@contrext.com>
- Date: Mon, 23 Jan 2017 15:57:31 -0500
So do you think we can call it a Lightweight
DITA standard if it doesn't include a mechanism for lightweight specialization?
I don't think we can call it DITA without
some kind of specialization support, and I don't think we can call it Lightweight
if that specialization support is the full DITA option of editing doctypes
by hand.
I'd also note that there are plenty
of different approaches to making specialization simpler and easier. Since
none of them are currently part of the standard, no one thinks of DITA
as being easy to specialize.
Making lightweight specialization part
of the standard accomplishes several goals:
- it enables interoperation of lightweight
templates across tool chains (for example, your ABCType can use my toolchain
to generate an HTML5 authoring template, someone else's toolchain to generate
a schematron validator, and a third person's toolchain to generate stylesheet
overrides that will automatically insert appropriate headings for specialized
sections into PDF, HTML and Word outputs)
- it explicitly addresses the complaint
that (full) DITA specialization is too complex to use. Any solution we
provide outside the standard space does not address complaints about the
standard itself
- it explicitly addresses the content
authoring needs of non-technical content strategists, who are key to one
of the domains Lightweight DITA is explicitly targetting
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 03:40 PM
Subject:
Re: [dita] My
increasing concerns about LwDITA and template-based specialization
Sent by:
<dita@lists.oasis-open.org>
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]