I am going to try and sort out the questions we need to consider:
Does the TC want to produce a DITA 1.3-related multimedia
domain? What are the costs and benefits?
Does the TC want to redesign the multimedia domain to be based
on DITA 2.0?
Does the TC want a redesigned multimedia domain to be use
object as a specialization base, or should the elements be added
to the base?
Does the TC want to update the object element for DITA 2.0?
Am I missing anything?
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 8/5/2019 2:06 PM, Robert D Anderson
wrote:
Our current definition of the object element is
a near-match for the object element as defined (15 years ago)
in HTML.
Looking at the latest HTML5 recommendation, it
looks like object has not changed much - it's added some
attributes we might want to consider, but is otherwise about
the same, with the same attributes / nested param elements. If
we are changing object around, I think we'd probably just want
to modify it so that it more closely matches the latest HTML5
version.
I don't think it really makes sense to add the
audio/video attributes to object just to enable easier
specialization of audio/video, unless those same attributes
are also valid on the latest HTML5 object element. Otherwise
we're overloading object with stuff that only makes sense for
two specialized elements, at which point I'd be more inclined
to treat them as base elements and let object do its own
thing.
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
Eliot Kimber ---08/05/2019 09:26:25
AM---I think keeping <object> in the base is a given.
But for 2.0 it could make sense for <object> to mov
From: Eliot
Kimber <>
To: Michael
Priestley <>, Chris Nitchie
<>
Cc: Alan
Houser <>, Carlos Evia
<>, "ligh >>
"
<>, Robert D Anderson
<>
Date: 08/05/2019
09:26 AM
Subject: [EXTERNAL]
Re: [dita] With multimedia coming, what happens to the object
element?
I think keeping <object> in the base is a
given.
But for 2.0 it could make sense for <object> to move to
attributes things that are attributes in HTML5 and are on
subelements today. That would then allow <audio> and
<video> to do the same but as proper specializations of
<object>.
I've certainly had clients in the past who used <object>
(or specializations of it) for things like custom browser
plugins, back when that was a thing people did.
The Web world has definitely evolved to a place where audio
and video are the primary embedded media types with other
things being handled in the browser using JavasScript and
canvas rather than plug-ins, so the need for <object> is
definitely lower but it's still needed, as others have pointed
out.
Cheers,
E.
--
Eliot Kimber
http://contrext.comÂ
ïOn 8/5/19, 9:15 AM, "Michael Priestley"
< on behalf of
> wrote:
 ÂI think the first
 Âquestion is: do we keep object? If we don't then it forces
a rebasing discussion,
 Âif we don't then it changes the question.
 Â
 ÂI think it does
 Âmake sense to keep object available in full DITA, just like
it's still
 Âavailable in HTML5. It handles more cases than audio and
video, and the
 Âdescription would need to be changed to reflect that.
 Â
 ÂIf we do keep
 Âobject then the question changes to: what is the value of
making audio/video
 Âpeers rather than specializations? What are the
specialization limitations
 Âwe're currently encountering, and are there other ways we
could address
 Âthem, other than ditching object as a parent?
 Â
 ÂMichael Priestley, Senior Technical Staff Member (STSM)
 ÂTaxonomy Specialist, Marketing Analytics
 Â[email protected]
 Â
 Â
 Â
 ÂFrom:
     Chris
 ÂNitchie <>
 ÂTo:
     Carlos
 ÂEvia <>
 ÂCc:
     Robert
 ÂD Anderson <>, Alan Houser
<>,
 Â"ligh >> "
<>
 ÂDate:
     2019/08/04
 Â02:00 PM
 ÂSubject:
     [EXTERNAL]
 ÂRe: [dita] With multimedia coming, what happens to the
object element?
 ÂSent
 Âby:    Â<>
 Â________________________________________
 Â
 Â
 Â
 Â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 <https://dita-ot.org/Â>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 <https://dita-ot.org/Â>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. [attachment
 Â"15838691.gif" deleted by Michael Priestley/Toronto/IBM]
[attachment
 Â"graycol.gif" deleted by Michael Priestley/Toronto/IBM]
 Â
 Â
 Â
