AW: Discussion item - do we still need itemgroup?

["Wegmann, Frank" <Frank.Wegmann@softwareag.com>]

Robert,

first of all, thanks for going again and again into the depths of the spec and coming up with reasonable questions about current practice given the spec's wording and grammar.

Now, I have seen writers use <itemgroup> here and there, especially in a task environment. But, then again, most documents at SAG still adhere to DITA 1.2, so that, at the time of writing, they simple could not think about whether there was an alternative named <div>.

In structural terms, I fully agree that, having <div> at our disposal and structurally behaving in the same way, it is well worth considering whether <itemgroup> should make the cut for 2.0. Maybe a bit more relevant in practice is the question of processing expectations that I'm glad you raised here as well. Personally, I think I would not go ahead for inline formatting for <itemgroup>, but if you have seen this, then it might be something worth mentioning when folks choose to switch to <div>.

So, I'm with you on this proposal proposal that you so elegantly presented as an open question:) If the TC would follow up on this, would it require another official proposal that we'd have to pass through all stages using the fast lane? Assuming that I would consider this as a stage 1 proposal...

Frank

---

Von: dita@lists.oasis-open.org <dita@lists.oasis-open.org> im Auftrag von Robert Anderson <robert.dan.anderson@oracle.com>
Gesendet: Montag, 19. Oktober 2020 17:21
An: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Betreff: [dita] Discussion item - do we still need itemgroup?

 

The <itemgroup> element has been around since the beginning of DITA. It’s the basis for most of the elements inside of a task step (like stepxmp, tutorialinfo, etc). In the specification, we’ve always defined it in the “specialization elements” section – it’s intended for cases like the task step, where you want to subdivide a list. A special container was used because we needed exactly that container for task steps, and because at the time we didn’t want to have an arbitrary “div” container available everywhere. Since DITA 1.0, that <itemgroup> element has been available exclusively in list items and in <dd> elements.

 

In DITA 1.3 we added the <div> element. In the base vocabulary, it’s available anywhere that itemgroup can go. It has exactly the same content model, exactly the same set of attributes, and it’s ideal for specializations.

 

I was editing the <itemgroup> element reference topic this weekend and found it hard to come up with an example – I kept coming back to “Why wouldn’t I do this with <div>?”

 

Which got me wondering – is <itemgroup> needed anymore? What would we lose if we got rid of it?

 

• I think everyone expects <div> to have formatting like it does in HTML (it’s a block). I’ve never been clear on formatting for <itemgroup>, and I’ve seen it formatted as both inline and as a block. So, for those who choose to format itemgroup as inline, they might end up with blocks.
• In theory, you can create a domain specialization of itemgroup and it only shows up within list items + DD. That would require a lot of constraints if you used <div>. I’ve never had any reason to do this, and it seems unlikely to me.
• The task specialization would require a change to @class values to base elements off of div. Because itemgroup and div have the same content models, everything else remains valid (no migration of source).
• Anyone who has specialized list items as we’ve done in task would have to make the same update, but it should be similarly simple.

 

I’m curious what others think about this?

 

Thanks,

Robert

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Sanjay Brahmawar (Vorsitzender/Chairman), Dr. Elke Frank, Dr. Matthias Heiden, John Schweitzer, Dr. Stefan Sigg - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Karl-Heinz Streibich - http://www.softwareag.com