Lightweight DITA SC

Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 Attachment: smime.p7s Description: S/MIME Cryptographic Signature

Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201

+1 for Magliery s response. Kris Sent from my iPad On May 22, 2019, at 3:00 PM, Magliery Tom < tom.magliery@justsystems.com > wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution:  https://xkcd.com/927/  . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? --  Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201

Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 -- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532

It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 -- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532

I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA.  :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution:  https://xkcd.com/927/  . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? --  Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 -- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532

My experience echos Kris's. For my projects that do involve complex tables (primarily parts catalogs), I would not even consider using Lightweight DITA. An MDITA mapping to CALS tables would be highly problematic. We would need to severely constrain the CALS table model. Even offering HTML tables would be similarly problematic. I admit that I'm moved by Patrick's arguments and passion. But we've long acknowledged on the LwDITA SC that the boundaries between LwDITA and DITA will be challenging for many. This is one example. Regarding MDITA/HDITA/XDITA ... my observations echo Mark's. I do see vendor/adopter activity around MDITA and XDITA, but not HDITA. I suspect a root cause is that few organizations author directly in HTML. -Alan On 5/22/19 3:47 PM, Kristen James Eberlein wrote: I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201

It's my understanding that you can already use HTML tables in MDITA, so no need for CALS tables there. And Patrick's comments were about XDITA. Mark On 23-May-19 8:35 AM, Alan Houser wrote: My experience echos Kris's. For my projects that do involve complex tables (primarily parts catalogs), I would not even consider using Lightweight DITA. An MDITA mapping to CALS tables would be highly problematic. We would need to severely constrain the CALS table model. Even offering HTML tables would be similarly problematic. I admit that I'm moved by Patrick's arguments and passion. But we've long acknowledged on the LwDITA SC that the boundaries between LwDITA and DITA will be challenging for many. This is one example. Regarding MDITA/HDITA/XDITA ... my observations echo Mark's. I do see vendor/adopter activity around MDITA and XDITA, but not HDITA. I suspect a root cause is that few organizations author directly in HTML. -Alan On 5/22/19 3:47 PM, Kristen James Eberlein wrote: I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201

Indeed, we have tables in MDITA.... but mapping a CALS table to MDITA would not be fun... and I don't think it can even be accomplished in GFM. -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Thu, May 23, 2019 at 12:34 PM Mark Giffin < mark@markgiffin.com > wrote: It's my understanding that you can already use HTML tables in MDITA, so no need for CALS tables there. And Patrick's comments were about XDITA. Mark On 23-May-19 8:35 AM, Alan Houser wrote: My experience echos Kris's. For my projects that do involve complex tables (primarily parts catalogs), I would not even consider using Lightweight DITA. An MDITA mapping to CALS tables would be highly problematic. We would need to severely constrain the CALS table model. Even offering HTML tables would be similarly problematic. I admit that I'm moved by Patrick's arguments and passion. But we've long acknowledged on the LwDITA SC that the boundaries between LwDITA and DITA will be challenging for many. This is one example. Regarding MDITA/HDITA/XDITA ... my observations echo Mark's. I do see vendor/adopter activity around MDITA and XDITA, but not HDITA. I suspect a root cause is that few organizations author directly in HTML. -Alan On 5/22/19 3:47 PM, Kristen James Eberlein wrote: I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind "standard #15" will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 Attachment: smime.p7s Description: S/MIME Cryptographic Signature

And ... we want to maintain equivalence between authoring formats as much as possible, and I believe we've accomplished this pretty well. So illegal in XDITA should translate to illegal in MDITA/HDITA . Nor should we add features to XDITA that cannot be (reasonably) mapped from MDITA/HDITA. Thinking out loud ... perhaps we could add row (and maybe column) spanning to simpletable for DITA 2.0? I acknowledge that I'm raising this without first checking the DITA TC archives, which likely contain threads of heated discussions on the issue, or a simple reason that this is not feasible. -Alan On 5/23/19 12:36 PM, Carlos Evia wrote: Indeed, we have tables in MDITA.... but mapping a CALS table to MDITA would not be fun... and I don't think it can even be accomplished in GFM. -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Thu, May 23, 2019 at 12:34 PM Mark Giffin < mark@markgiffin.com > wrote: It's my understanding that you can already use HTML tables in MDITA, so no need for CALS tables there. And Patrick's comments were about XDITA. Mark On 23-May-19 8:35 AM, Alan Houser wrote: My experience echos Kris's. For my projects that do involve complex tables (primarily parts catalogs), I would not even consider using Lightweight DITA. An MDITA mapping to CALS tables would be highly problematic. We would need to severely constrain the CALS table model. Even offering HTML tables would be similarly problematic. I admit that I'm moved by Patrick's arguments and passion. But we've long acknowledged on the LwDITA SC that the boundaries between LwDITA and DITA will be challenging for many. This is one example. Regarding MDITA/HDITA/XDITA ... my observations echo Mark's. I do see vendor/adopter activity around MDITA and XDITA, but not HDITA. I suspect a root cause is that few organizations author directly in HTML. -Alan On 5/22/19 3:47 PM, Kristen James Eberlein wrote: I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA. :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution: https://xkcd.com/927/ . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? -- Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 -- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532

No from me on changing the content model of simple table.  Kris Sent from my iPad On May 23, 2019, at 1:08 PM, Alan Houser < arh@groupwellesley.com > wrote: And ... we want to maintain equivalence between authoring formats as much as possible, and I believe we've accomplished this pretty well. So illegal in XDITA should translate to illegal in MDITA/HDITA . Nor should we add features to XDITA that cannot be (reasonably) mapped from MDITA/HDITA. Thinking out loud ... perhaps we could add row (and maybe column) spanning to simpletable for DITA 2.0? I acknowledge that I'm raising this without first checking the DITA TC archives, which likely contain threads of heated discussions on the issue, or a simple reason that this is not feasible. -Alan On 5/23/19 12:36 PM, Carlos Evia wrote: Indeed, we have tables in MDITA.... but mapping a CALS table to MDITA would not be fun... and I don't think it can even be accomplished in GFM. --  Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 On Thu, May 23, 2019 at 12:34 PM Mark Giffin < mark@markgiffin.com > wrote: It's my understanding that you can already use HTML tables in MDITA, so no need for CALS tables there. And Patrick's comments were about XDITA. Mark On 23-May-19 8:35 AM, Alan Houser wrote: My experience echos Kris's. For my projects that do involve complex tables (primarily parts catalogs), I would not even consider using Lightweight DITA. An MDITA mapping to CALS tables would be highly problematic. We would need to severely constrain the CALS table model. Even offering HTML tables would be similarly problematic. I admit that I'm moved by Patrick's arguments and passion. But we've long acknowledged on the LwDITA SC that the boundaries between LwDITA and DITA will be challenging for many. This is one example. Regarding MDITA/HDITA/XDITA ... my observations echo Mark's. I do see vendor/adopter activity around MDITA and XDITA, but not HDITA. I suspect a root cause is that few organizations author directly in HTML. -Alan On 5/22/19 3:47 PM, Kristen James Eberlein wrote: I have always used simple tables. In 17 years of using DITA (14 years of daily use), I never used row or column spanning until this past January. And it was very much a presentational hack. Kris Sent from my iPad On May 22, 2019, at 3:34 PM, Mark Giffin < mark@markgiffin.com > wrote: It's the Bane of Tables. Tables really are rather evil. They always cause lots of trouble, no matter what you are authoring in: Word, Markdown, HTML, DITA, a whiteboard. Tables are ridiculously complex markup/programming. Tables are a thing unto themselves. But Patrick B's argument has merit. It's the best argument I've heard for CALS tables in XDITA. I remember discussing this heavily in lwdita meetings. I think it's possible that people really want something simple, except when it comes to tables. I personally have never had a client that used simpletable. Has anyone else? On the other side, who has expressed interest in XDITA? I'm thinking that only vendors are messing with XDITA. All the interest outside of vendors that I have personally seen for lwdita is for MDITA. Also, I believe easyDITA is based on an XML database. Can it handle markdown files? Mark On 22-May-19 12:22 PM, Alan Houser wrote: Of course, the people behind standard #15 will deny that it competes in any way with the other 14 standards. I'll make this claim on behalf of Lightweight DITA.  :-) What I really want to know ... is table markup semantic or presentation-oriented? I miss the days when you could raise this question at an SGML/XML conference, and watch fistfights break out. -Alan On 5/22/19 3:00 PM, Magliery Tom wrote: Modulo the specific tools being held up as examples, I seem to recall an entire conference (or possibly conference track?) dedicated to this debate/discussion in 1996. And I'm not nearly as old as some markuppers. There is no solution*, there is only compromise. *Well, there is one solution:  https://xkcd.com/927/  . mag On Wed, May 22, 2019 at 8:33 AM Carlos Evia < cevia@vt.edu > wrote: Dear Lightweight DITA subcommittee members, I cancelled our call scheduled for May 27th because it is a holiday here in the US (and there's no childcare!). I don't want to wait, however, for our next call to address a concern/question from Patrick Bosek at easyDITA. Patrick has been in touch with me as he works on an implementation of LwDITA, and he had some concerns about the lack of CALS tables in XDITA. With his permission, I am pasting his comments here and I hope that we can discuss via email before our next call. Best, Carlos ----- From Patrick Bosek: Ok, that seems like a pretty significant issue to me. Without row/col spanning I think LwDITA is going to really struggle to find an audience. Here's the thing, you've basically got two audiences for LwDITA: normal people who don't know DITA and tech writers that think DITA is too complex. Normal people who don't know DITA: ... are going to be coming from one of 3 formats, Word, Google Docs, or some HTML editor. All of these options support row/col spanning and are going to be expected by these authors. Further, when they start using LwDITA and find out they can't create the table they need to create, they're completely stuck, there's no workaround. This is actually one of the primary reasons we configured simpletable off in easyDITA*, when people would add simpletables we would invariably get a support ticket claiming easyDITA was broken because they couldn't format their table. Then when we explained it was because simpletable didn't support this, we'd get a range of reactions, but none of them were happy or understanding. Tech writers that think DITA is too complex: ... will be coming from something like Madcap, Markdown, FrameMaker, or a wiki or some sort (probably Confluence). All of these options will also contain this capability, and I think almost any technical publication past the most basic will require a non-standard table. * the other reason we configured simpletable off is because not a single customer uses it. I think a potential solution is to simply use HTML tables. I know there are some issues with backwards compatibility, but I think simpletables are going to be insufficient for real use case. And the result of this is that people who come to try LwDITA will run into this impassible roadblock, and become extremely frustrated, where at best, they'll move into regular DITA and advocate that other people avoid LwDITA. Thoughts? --  Carlos Evia, Ph.D. Associate Professor of Communication Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201 -- Alan Houser Group Wellesley, Inc. Consultant and Trainer, Technical Publishing arh on Twitter 412-450-0532