OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Tables and more


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]