You're right Robert, it's the same class-based specialization
mechanism in lwdita as in full DITA. Anything the tool does that
results in a specialized DTD/RNG could also be accomplished by hand,
in the ways it's been done for years already.
The template-based specialization tool we've been working on was
never intended to be "The Standard Way" for doing it. It was just to
give the template mechanism more reality for people, and to have a
proof of concept. And to fit in with the "simple DITA" theme of
Lightweight DITA.
While I have been enjoying working on this tool, I can appreciate
the concerns that Kris expressed, they seem valid. I hope to hear
what Michael P has to say on this.
Mark Giffin
Mark Giffin Consulting, Inc.
http://markgiffin.com/
On 1/19/2017 9:14 AM, Robert D Anderson
wrote:
Hi,
> I feel quite strongly that it is important to have a
non-proprietary
> specialization mechanism available in the LwDITA spec if
class-based
> specialization is not supported.
As far as I'm aware, if specialization itself is supported in
LwDITA, it has to be class-based? Nothing I've heard so far
would suggest a whole new specialization mechanism. If one is
created, LwDITA would no longer be compatible with full DITA.
To me - it's not always clear whether we are talking about:
1) DITA rules (the DTD / RNG declarations that say what is
legal)
2) DITA specialization (DITA rules in a DTD / RNG that map your
new elements back to old ones)
3) A piece of software that helps you generate #2
It cannot be possible that the specification requires use of a
specific piece of software from #3 in order to create the rule
set for #2. That's because if it's possible to generate a
DTD/RNG with specialized elements, then it's also possible to
create one by hand (or with a better tool that somebody else
comes up with).
I'm imagining the following conversation:
Author A: "Here, use this specialized LwDITA DTD, it has all the
elements we need"
Author B: "Great! Wait, did you create this by hand, or did you
use the template based tool described in the spec?"
Author A: "No, I came up with an even easier way to do it!"
Author B: "Sorry ... spec says we had to use the template"
As mentioned in the call last week, I still feel uncertain here
because I don't know all the details around this tool. But as
I've understood it so far, the idea is:
* The LwDITA spec will lay out rules for one specific
implementation of the software in #3
* To enable that software, it will also add one or more
attributes to every LwDITA element
* Those attributes are defined in terms of the software
* As such, they are meaningless in actual LwDITA content (they
are only useful in the one-off process of generating a
specialized DTD/RNG)
If I understood Kris's original note, she's questioning whether
it's reasonable for the specification to add those attributes to
everything everywhere. She's also questioning whether it's
appropriate for the spec to lay out a specific design for the
software in #3, when any number of alternate methods could be
used to generate a specialized rule set.
Now, the big assumption -- assuming all of that is correct, I
share Kris's concerns, which reflect of the nervousness I tried
to get across in the call last week. The good news is that
happily, I don't think my nervousness carries over into any
other aspect of LwDITA...
<dita@lists.oasis-open.org> wrote on 01/19/2017
10:33:45 AM:
> From: Rob Hanna <rob@precisioncontent.com>
> To: Carlos Evia <cevia@vt.edu>, Kristen James
Eberlein
> <kris@eberleinconsulting.com>
> Cc: DITA TC <dita@lists.oasis-open.org>
> Date: 01/19/2017 10:34 AM
> Subject: RE: [dita] My increasing concerns about LwDITA
and
> template-based specialization
> Sent by: <dita@lists.oasis-open.org>
>
> I feel quite strongly that it is important to have a
non-proprietary
> specialization mechanism available in the LwDITA spec if
class-based
> specialization is not supported. If we are targeting SMEs
as a
> primary user of LwDITA than I believe it is important to
have the
> capability to present SMEs with a tagging vocabulary that
is
> familiar to the SME and that provides adequate guidance
during
> authoring. This has always been the strongest argument
for
> specialization in my opinion.
>
> We shouldn’t be targeting the specialization mechanism
at the SME
> where simplification is the main goal. The SME will
always be able
> to create templates for authoring without the need for
> specialization. Specialization is always going to require
a thorough
> understanding of information architecture regardless of
how simple
> it is to perform specialization. Just because it is
simpler doesn’t
> mean that it should be a common task in most authoring
environments.
>
> In my opinion, the development of new tags and
structures to support
> specialization is no different than supporting the
DITAval
> vocabulary for conditional processing.
>
> My two cents…
>
> Cheers,
> Rob Hanna
>
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
> On Behalf Of Carlos Evia
> Sent: January 19, 2017 9:21 AM
> 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
>
> Dear Kris and all,
>
> I don't have strong feelings about the specialization
mechanism
> being a part of LwDITA. I am used to it because I have
seen it as a
> component of our work in the subcommittee since day one.
To be
> honest, the promise of simplified specialization is
sweet, but I
> have previously expressed concern about the spaghetti
topics that
> users could create following the template-based
mechanism. We have
> seen a demo of those with the marketing draft, which
probably is
> useful for its authors, but a little too complex to be
called lightweight.
> Don pointed out that users can create such spaghetti
topic types now
> with DITA 1.x's specialization mechanism, and that is
right... but
> those don't come with the "lightweight" label.
> I defer defense of the specialization mechanism to
Michael as its
> original designer. I support Michael's decision as his
co-chair, but
> keep my concerns about the lightweight nature of topic
types created
> under this specification/tool.
>
> Best,
>
> Carlos
>
>
> --
> Carlos Evia, Ph.D.
> Director of Professional and Technical Writing
> Associate Professor of Technical Communication
> Department of English
> Center for Human-Computer Interaction
> Virginia Tech
> Blacksburg, VA 24061-0112
> (540)200-8201
>
>
> On Thu, Jan 19, 2017 at 8:14 AM, Kristen James Eberlein
<
> kris@eberleinconsulting.com> wrote:
> 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
>
|