Fwd: Re: [dita-lightweight-dita] LwDITA DTD/feature questions

-------- Forwarded Message --------

Subject:	Re: [dita-lightweight-dita] LwDITA DTD/feature questions
Date:	Mon, 5 Jun 2017 12:18:56 -0500
From:	Robert D Anderson <robander@us.ibm.com>
To:	Michael Priestley <mpriestl@ca.ibm.com>
CC:	arh@groupwellesley.com, Carlos Evia <cevia@vt.edu>, dita-lightweight-dita@lists.oasis-open.org <dita-lightweight-dita@lists.oasis-open.org>

Interesting ... I hadn't even noticed that we're including specialized <object> elements but not including <object> itself. The pains of joining the committee late, I suppose.

I wouldn't want to call LwDITA topicref element "specialized from" full DITA topicref, just because working on the DITA 1.3 spec made me far more obsessive over terminology than I ever was for 1.2 and earlier. But in theory, you could say that LwDITA <topicref> is a constrained version of full DITA <topicref>, while <keydef> both specialized from + less constrained than full DITA topicref.

This all feels strange but I'm trying to think of it as "something new" rather than "something DITA that follows the existing definition of specialization". Regardless of how we handle it, I do think that this calls for much closer attention to how we describe specialization in LwDITA.

With DITA 1.3 today -- every specialization must refer back to something in the base. So any application that supports the base + supports specialization has at least *some* level of support for every specialization.

Today, LwDITA spec is declaring specializations of an element that is not part of LwDITA. Which got me tugging a lot of threads:
1. Can somebody else create new specializations of <object> in LwDITA, or must they be specializations of the existing multimedia elements?
2. If they can specialize base <object>: should applications be expected to support <object>, even if it's not part of LwDITA? I think the answer has to be "yes" or else those specializations would have no fallback support.
3. If yes - can a LwDITA user create their own doctype that actually includes <object> directly? I'd have said "no" when I started this email...
4. If a LwDITA user can use or specialize <object> (which isn't in LwDITA), can they do the same with other elements like <cite>?
5. In general: if the LwDITA spec can specialize by pulling full DITA features that are not in LwDITA (like object, like keydef/@processing-role) ... can LwDITA users do the same?

For #5 the answer must be no. Because if it's yes, then LwDITA applications must be prepared for specialized LwDITA to have any core DITA feature ... which means there is no such thing as a LwDITA application, only full DITA applications. But if the answer really is "no" -- that is, "The spec can pull core features into specializations but you cannot" -- then I'm very curious to see how we explain that.

For what it's worth - tugging at all of these threads got me in a bit of a panic, so I sent some messages to Michael, who clarified some things:
- <object> is not part of LwDITA, so if you specialize from <object>, you should not expect LwDITA apps to work.
- Same for other elements and attributes of full DITA not in LwDITA
- Meaning <keydef> can use @processing-role but if you specialize your own topicref and use it, you should not expect it to work.
- But LwDITA apps should support it on <keydef> because that's the spec, and it's still a nice tidy subset of full DITA.
- And you could specialize <keydef>, or <video>, or any LwDITA "core" element, and use what's there, but as usual you can't add your own new stuff

All of which sounds reasonable / justifiable, just calls for us to write up a really nice explanation to make sure this is clear for both LwDITA architects and for LwDITA implementers.

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

Michael Priestley---06/05/2017 10:17:43 AM---Hi Robert, For processing-role on topicrefs vs keydef -

From: Michael Priestley/Toronto/IBM
To: "Robert D Anderson" <robander@us.ibm.com>
Cc: arh@groupwellesley.com, Carlos Evia <cevia@vt.edu>, "dita-lightweight-dita@lists.oasis-open.org" <dita-lightweight-dita@lists.oasis-open.org>
Date: 06/05/2017 10:17 AM
Subject: Re: [dita-lightweight-dita] LwDITA DTD/feature questions

Hi Robert,

For processing-role on topicrefs vs keydef -

If you think of it as both topicref and keydef being derived/specialized/constrained from full topicref, there's no issue from a DITA perspective.

If we want keydef to be considered as a specialization *within* lightweight DITA then you are correct.

But we do have other specializations in LwDITA that are clearly not specializations *within* LwDITA. For example, the multimedia specializations are off of object, which we're not even including in LwDITA.

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com

From: "Robert D Anderson" <robander@us.ibm.com>
To: arh@groupwellesley.com
Cc: Carlos Evia <cevia@vt.edu>, "dita-lightweight-dita@lists.oasis-open.org" <dita-lightweight-dita@lists.oasis-open.org>
Date: 06/05/2017 11:00 AM
Subject: Re: [dita-lightweight-dita] LwDITA DTD/feature questions
Sent by: <dita-lightweight-dita@lists.oasis-open.org>

Not that I'm out to make things more complicated, but with regards to @processing-role...

It's sort of a one-stop-shop for several original DITA attributes. It means "Don't put this in the TOC, don't generate links based on this instance, don't print, etc". None of those attributes are part of LwDITA, and that seems right to me, as they're for more complex scenarios.

But without @processing-role, our key definitions in particular become full-on parts of the TOC, link structure, and so on. We need to have that attribute, as the only way to distinguish something that's just part of the map for reference (most often, keys) and something that's actual content. The <keydef> element in particular needs to set processing-role="resource-only" as a default value in order to work properly.

And to answer the logical follow-up ... I don't think we can have @processing-role *without* having it on <topicref>. The <keydef> element is specialized from <topicref>, and if we're adding a core processing attribute on the specialization (but not on the base), then we've really broken the rules of specialization.

If it helps anything, I liked the answers to all the other questions...

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

Alan Houser ---06/05/2017 09:23:07 AM---Hi Mark and Carlos, Thanks! All answers align with my expectations. Apologies for asking

From: Alan Houser <arh@groupwellesley.com>
To: Carlos Evia <cevia@vt.edu>
Cc: "dita-lightweight-dita@lists.oasis-open.org" <dita-lightweight-dita@lists.oasis-open.org>
Date: 06/05/2017 09:23 AM
Subject: Re: [dita-lightweight-dita] LwDITA DTD/feature questions
Sent by: <dita-lightweight-dita@lists.oasis-open.org>

Hi Mark and Carlos,

Thanks! All answers align with my expectations. Apologies for asking about @outputclass -- that's definitely there.

-Alan

---

On 6/5/17 6:21 AM, Carlos Evia wrote:
The only filtering attribute available in LwDITA is @props. My students used it last semester in XDITA topics.
I think processing-role is too complex for LwDITA map users... just my opinion.

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 Sun, Jun 4, 2017 at 11:02 PM, Alan Houser <arh@groupwellesley.com> wrote:
Colleagues,

A few questions about the Lightweight DITA DTDs and LwDITA features --

- The content model and attribute set for <data> is different in maps and topics (content model: <data> in <topic> allows #PCDATA; <data> in <map> does not. And the attributes are different). Is that intentional?

- LwDITA does not provide the DITA filtering attributes? (O.K. with me; just confirming).

- LwDITA does not provide a generic metadata container attribute (e.g., @outputclass)?

- Should we provide @processing-role on <topicref>? I'm thinking of the use case of referencing a "keydef-only" ditamap (@processing-role = "resource-only").

-Alan

-- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532

dita message