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: Kristen James Eberlein <kris@eberleinconsulting.com>
- Date: Sat, 21 Jan 2017 22:33:03 -0500
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]