[dita-lightweight-dita] Tables and more

["Jang F.M. Graat" <jang@jang.nl>]

I was in too much of a hurry to check where this mail went to, so here it is again, now addressed to the list instead of only to Fredrik.

Kind regards from Amsterdam

Jang

The Content Era, LLC
EMEA Office
Amsterdam - Netherlands
+31 646 854 996
www.thecontentera.com



Begin forwarded message:

> From: "Jang F.M. Graat" <jang@jang.nl>
> Subject: Re: [dita-lightweight-dita] Tables and more
> Date: 16 Jun 2015 17:11:11 GMT+2
> To: Fredrik Geers <fgeers@sdl.com>
> 
> Hi,
> 
> I was in a car racing back to Amsterdam yesterday so I missed another call. I do want to give my reaction to the points noted by Fredrik and throw in my 2 cents, as I have just been struggling with the table versus simpletable and do find the simpletable too simple and the CALS table too complicated.
> 
> The only thing I would like to add to a simpletable is a title. In my opinion, that was a serious mistake in the original design - stating that simple tables do not need table groups and straddling is one thing, but kicking out a table title in the same broad sweep was restricting the model way too much. Now I have to use the full, bloated, CALS model even if my simple is a straightforward shopping list, just because I want to call it a shopping list and make sure the reader interprets it as such. The other option would be to place the table in a section which then gets a title and does not contain anything else, which is a totally ugly solution with unwanted side-effects.
> 
> I would NOT allow any kind of straddling, as this immediately brings lots of complexity into the model, as well as in the software that supports it. How are you going to identify which cells are combined into a single cell via straddling? Can you allow column straddling but disallow row straddling? And what if the user wants to straddle one cell from the header row together with one cell in the first body row? I can think of many more scenarios that would be unwanted for a simplified authoring AND processing experience. If people really need straddling in tables they should choose the CALS table with all its features.
> 
> That was 1 cent, now the other one...
> 
> About sections:
> 
> I completely agree that, once you have used a section in a topic body, you should not be able to add content above that section level, as this is causing ambiguity in all cases where full content indenting is not forced in the output. Also, to further reduce ambiguity, I would make a title mandatory in a section, instead of optional. If you want to introduce a section, give it a title to tell the reader what the section is about.
> 
> 
> Kind regards from Amsterdam
> 
> Jang
> 
> The Content Era, LLC
> EMEA Office
> Amsterdam - Netherlands
> +31 646 854 996
> www.thecontentera.com
> 
> 
> 
> On 16 Jun 2015, at 16:48, Fredrik Geers <fgeers@sdl.com> wrote:
> 
>> Hi all,
>> 
>> After yesterday’s call I have some more thoughts on the subjects we talked about.
>> 
>> First of all, the discussion of the table model: simpletable vs constrained CALS table model. You can argue that a table is like svg or mathml, and a simpler model like with LW DITA doesn’t have to mean simpler tables. From a author’s perspective having cell spanning doesn’t add a lot of complexity – it’s a very common concept, exposed in MS Word and other common tools for years.
>> Maybe we have to look at it from this angle:  why do we want to have a simpler table model than the full CALS model?
>> To enable a markdown representation of a document with a table? To make it easier to process content? To make it easier to author content in an editor?
>> Or we can look at it from the perspective of the “complex” features in CALS, what is it we do not want?
>> Cell spanning? Separators/frames? Cell alignment? Multiple tgroups? Pgwide?
>> 
>> Another thing I noted down was the comment someone made: “nested tables are not possible in DITA, at least not directly”. I haven’t found any of these situations in the current proposal yet, but I think we should really try to prevent these situations in LW DITA: that something is not valid, but as soon as you wrap it in a ph (for example) it is. I’ll be looking for loopholes like that in any future proposals, but I’d like to invite everyone to help me in catching situations like that.
>> 
>> Related to Jan’s comment on reducing ambiguity and the subject of content that’s not in a section: the current DITA topic not only allows content before sections or without sections at all, but it also allows content after and in between sections. Do I understand correctly that in LW DITA we’re changing that, and only allow other sections after a section? (I hope so?)
>> 
>> And finally, the more I think about it, the more I realize that for this initiative to really work well we should make creating specializations as simple as possible. Similar to how web cms’s allow to create different page types by combining different component types in some kind of ui, this should be a task that anyone can do without DTD/XSD/RNG knowledge. Perhaps this is an area where us tool vendors can help out, but for that to be as successful, it helps if it is conceptually as straightforward as possible.
>> 
>> Fredrik Geers | Product Owner SDL LiveContent Create/SDL Xopus | SDL |  (t) +31 (0)20 201 0500 | (e) fgeers@sdl.com
>> 
>> 
>> 
>> www.sdl.com 
>> 
>> 
>> SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.
>> 
>> SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. 
>> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.
>> 
>> 
>> 
>> This message has been scanned for malware by Websense. www.websense.com
>> 
>