OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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...

Regards,

Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group


E-mail: robander@us.ibm.com
Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA


<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

>  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]