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 12:54:32 -0500
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]