Michael, thanks for expanding on your vision for the
template-based specialization mechanism. It does clarify your
thinking to me.
The main problem I see, however, is that this vision (in more
than the broadest details) exists primarily in your head. It has
not been socialized to others in the Lightweight DITA subcommittee
(or the DITA TC) nor has it been instantiated in any design
documents. That makes it difficult/impossible to include it in a
release.
Do you have any thoughts on how to remedy this? Do you have
additional time to spend working on this?
I am interested in seeing a release of Lightweight DITA in the
near future, definitely before DITA 2.0.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
On 1/21/2017 10:33 PM, Michael
Priestley wrote:
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
|