If we have no 1.3 domain, then LwDITA will not be interoperable with DITA 1.3. If itâs different between 1.3 and 2.0 itâll involve migration costs. The genesis of all this was the desire to make LwDITA interoperable with official, TC-provided DITA 1.3.
Best,
Chris
On Aug 4, 2019, at 1:24 PM, Carlos Evia <> wrote:
This is an interesting and scary conversation. Scary particularly for me:
If we redesign the multimedia domain to be 2.0 compatible and look more like HTML5 (with properties as attributes instead of elements), the LwDITA committee note and my book on LwDITA will be obsolete/inaccurate. However, I wonder if that is the right
thing to do if there isn't a real need for a 1.3-compatible multimedia domain.
So... the question is: with the LwDITA spec not really being released months/years before 2.0, do we need a 1.3-compatible multimedia domain to make LwDITA 1.3-compliant? Should we just aim for LwDITA-2.0 congruence?
If we need a small taskforce to explore what a new multimedia domain would look like if we don't need 1.3 compatibility, count me in.
Carlos
--
Carlos Evia, Ph.D.
Associate Professor of Communication
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
On Sat, Aug 3, 2019 at 7:55 PM Robert D Anderson <> wrote:
Thanks Alan.
About this:
> I experienced whiplash when I learned that the review target was DITA 2.0, not the DITA 1.3 multimedia domain that we had long planned. But if 2.0 is the target, ...
The original goal for this markup was definitely a DITA 1.3 compatible domain that would 1) be usable by LwDITA, and 2) carry forward more or less unchanged into DITA 2.0. LwDITA was the driver behind that -- having a 1.3 compatible domain is of course a nice
thing to have, but the domain design was driven by the desire to have a LwDITA that is compatible with DITA 1.3 and (ideally) DITA 2.0.
If we make them base elements, then it's of course still possible to write a DITA 1.3 domain using the current model, but audio/video content marked up using that domain would need to be migrated before it could become DITA 2.0.
All of this is why I was a little hesitant to raise the idea...
Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification
Marketing Services Center
E-mail:
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA
<15838691.gif>
<graycol.gif>Alan Houser ---08/02/2019 05:50:14 PM---Thanks, Robert ... good observations and comments. I experienced whiplash when I learned that the re
From: Alan Houser <>
To:
Date: 08/02/2019 05:50 PM
Subject: [EXTERNAL] Re: [dita] With multimedia coming, what happens to the object element?
Sent by: <>
Thanks, Robert ... good observations and comments.
I experienced whiplash when I learned that the review target was DITA 2.0, not the DITA 1.3 multimedia domain that we had long planned. But if 2.0 is the target, I don't believe we would have designed the multimedia support in the way that we did. Using
child elements to specify properties makes the vocabulary much more verbose than otherwise (9 element types instead of 2), and is especially awkward for Lightweight DITA.
I like the idea of adding audio and video to the DITA 2.0 base. I would favor defining attributes to specify properties, as does HTML5.
We can still release a DITA 1.3 multimedia domain as currently designed, if it's the will of the TC to do so.
I'll note that this approach would have ramifications for Lightweight DITA, which I have barely begun to think through.
-Alan
On 8/2/19 4:52 PM, Robert D Anderson wrote:
Keith had a fascinating comment in the multi-media review that got me thinking - does the presence of audio and video supersede the need for the object element?
My gut reaction was - maybe so, but only if we make audio/video part of the base vocabulary (they can't be based on object and still mean object is unnecessary). But digging further, it's clear other uses are possible, so I don't think we can say the new elements
supersede it. I've only used objects for audio/video, but here's a good HTML5 example of using the element to embed a PDF:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object
At a minimum, Keith's comment points out that we need to clean up our reference topic for <object> so that it no longer talks about audio/video.
Beyond that, this comment -- and other chatter on the list during the review -- has me wondering about how much simpler things would be if audio/video were just base elements, rather than specializations of object. I know why we didn't consider that initially,
and I probably risk the wrath of Kris or Chris in asking, but I wonder if at this point it's worth reconsidering? It would give us more flexibility in the definition to address some of the review comments that have come in. The down side is that it would rule
out a backwards-compatible domain that works with DITA 1.3 and DITA 2.0. That said, the currently-defined domain markup would have a simple migration path into a DITA 2.0 model that uses base elements.
I don't want to go too far down that path without more discussion though...
Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification
Marketing Services Center
E-mail:
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA
<15838691.gif>
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532
The content of this email and any attached files are intended for the recipient specified in this message only. It may contain information that is confidential, proprietary, privileged, and/or exempt from disclosure under applicable law. It is strictly forbidden
to share any part of this message with any third party or rely on any of its contents, without the written consent of the sender. If you received this message by mistake, please reply to this message and follow with deletion of the original message, any copies
and all attachments, so that Oberon Technologies can ensure such a mistake does not occur in the future.
