Re: [dita] Re: Stage One Proposal: Change the specialization base of ima

I am intrigued by getting rid of the utilities domain and the aforementioned consequences, but I want to toss out one other idea about imagemap: Could area be derived from div?

The derivation of imagemap from fig feels like it might have gone like this:

1. "We have this thing that contains an image and some other stuff. Aha, so does fig."

2. But wait: "Now there are these other elements inside imagemap that we need to group together".

3. "Well, our only option for that is figgroup"

But nowadays, we have div, too, and I think we would have chosen that instead of figgroup.

I don't know if using div for area would solve the problem with imagemap that originated this discussion. Would it?

And even if it would, would we still rather add imagemap to the base? That would mean adding FOUR more elements to the base, right?

mag

On Tue, Jul 9, 2019 at 6:17 AM Chris Nitchie <chris.nitchie@oberontech.com> wrote:

Would it be reasonable to add <imagemap> and its related elements to the base vocabulary? An image map is not really (IMO) a figure; it's just specialized from there out of technical convenience and a lack of other viable alternatives. If a construct cannot be described as a kind of something in the base vocabulary, I think it's a pretty good candidate for adding it there. If it were in the base, we could make it available wherever we wanted.

Currently, <imagemap> is in the Utilities domain. It and its related elements are the only thing in the Utilities domain other than <sort-as> which, similar to <imagemap>, I think should probably be promoted to the base vocabulary, now that I look at it. While I suppose you could say sorting instructions are a kind of <data>, <sort-as> performs a pretty critical function in many common use cases; having it off in an obviously "I-don't-know-what-to-call-it-so-let's-just-call-it-Utilities" domain is less than ideal.

So maybe this should be a Stage 1 proposal for adding the current Utilities domain to the base vocabulary.

Chris

From: <dita@lists.oasis-open.org> on behalf of Graydon Saunders <graydon@precisioncontent.com>
Date: Monday, July 8, 2019 at 9:49 PM
To: Zoe Lawson <zoelawson17@hotmail.com>, DITA TC <dita@lists.oasis-open.org>
Subject: [dita] Re: Stage One Proposal: Change the specialization base of imagemap

If the goal is to specialize the imagemap element from a different base element than fig,

<imagemap class="+ topic/fig ut-d/imagemap ">

<image class="- topic/image " />

<area class="+ topic/figgroup ut-d/area ">

<shape class="+ topic/keyword ut-d/shape " />

<coords class="+ topic/ph ut-d/coords " />

<xref class="- topic/xref " />

</area>

</imagemap>

I think the difficulty is likely to be the area element child of imagemap. The area element is specialized from figgroup; figgroup occurs only as a child of fig or figgroup. (Or equation-figure, specialized from fig.) It'd be difficult to specialize imagemap from another element without adding figgroup to that element's content model.

Because imagemap is specialized from fig, it could have its content model changed to include fig's optional title:

<imagemap class="+ topic/fig ut-d/imagemap ">

<title class="- topic/title " />

<image class="- topic/image " />

<area class="+ topic/figgroup ut-d/area ">

<shape class="+ topic/keyword ut-d/shape " />

<coords class="+ topic/ph ut-d/coords " />

<xref class="- topic/xref " />

</area>

</imagemap>

If you want specifically to allow:

<fig class="- topic/fig ">

<title class="- topic/title " />

<imagemap class="+ topic/fig ut-d/imagemap ">

<image class="- topic/image " />

<area class="+ topic/figgroup ut-d/area ">

<shape class="+ topic/keyword ut-d/shape " />

<coords class="+ topic/ph ut-d/coords " />

<xref class="- topic/xref " />

</area>

</imagemap>

</fig>

the simplest approach is to change the content model of the fig element to allow fig as a child, which would then logically permit imagemap and other specializations of fig as children of fig.

What the committee considers desirable I could not say.

Graydon Saunders | Publishing Solutions Developer | Precision Content
Direct: +1 (647)265-8500 x106| Email: graydon@precisioncontent.com | www.precisioncontent.com

Unlock the Knowledge in Your Enterprise™

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. ©2019, Precision Content Authoring Solutions Inc, Mississauga, Ontario, Canada

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Zoe Lawson <zoelawson17@hotmail.com>
Sent: 08 July 2019 20:30
To: DITA TC
Subject: [dita] Stage One Proposal: Change the specialization base of imagemap

Originally, <imagemap> was a specialization of <fig>. This means you cannot use an <imagemap> directly inside of a <fig>, which makes it complicated to add a title to your image.

You can work around this by using a <div> inside of the <fig>, but that seems like an extra layer of complexity.

If we change the specialization base of <imagemap> from <fig> to something slightly more generic such as <div>, that may simplify the adding of a title (or other content) around an <imagemap> in a <fig>.

I would like some technical assistance determining which element makes the most sense to specialize from.

Thanks,

Zoë Lawson

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.

dita message