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