For TC attention.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
-------- Forwarded Message --------
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.
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...
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
|