Re: [dita-lightweight-dita] Tables and more

[Michael Priestley <mpriestl@ca.ibm.com>]

Hi Fredrik,

Thanks for kicking off the discussion!

On simple vs complex tables: I agree
that tables don't have to be complex - but that said, there are a growing
number of authoring and delivery platforms that aren't really friendly
to complex tables. They tend not to be responsive (ie viewable usefully
on different device sizes, especially small ones), and simple web authoring
platforms (like markdown, or medium, or many of the HTML5 editors) just
don't support complex tables (or in some cases any tables at all). Complexity
in these contexts really means anything beyond a heading (including sizing
of rows/columns, picking border types, column spans, etc.)

Given that DITA already has the concept
of a simple table, as distinct from the full CALS model, I think it probably
does make sense to stick with simple for out-of-the-box enablement, but
with guidance available on how to add back in the full CALS model if needed.

Re avoiding nested tables: the simplified
content model of lightweight DITA (specifically, no block elements inside
p) should solve this for most cases, but not all. There's still the case
of <xref> not being available in <title> directly, but still
being available inside <ph>. I'm open to suggestions on how to avoid
this. I can't see a way without breaking compatibility with full DITA (by
allowing xref inside title) or making authoring harder (by disallowing
xref inside ph).

Re sections ambiguity: that's correct,
the current model for the lightweight DITA topic requires all-section content
after your first section (you can still have block-level content outside
a section before the first section, just not after). So it's more like
the concept model in full DITA.

Re making specializations easier: I
couldn't agree more. This is something I really want to include in the
initial spec. The two main approaches we've talked about are:

1 - a specialization for authoring specializations:
you document the specialization in a topic (or several topics and a map),
then generate from there - including schemas (DTD, RNG, XSD), documentation,
etc.  Authoring tool vendors would be able to create their own support
for the specialization, generating whatever artifacts they require in addition,
like authoring templates/guidance.

2 - or specialization by example: you
create a sample of the kind of topic or map you want to create, then annotate
it with attributes to identify specialization, potentially additional attributes
or elements to make complex content models explicit (like when you're showing
one example but there are several valid but mutually exclusive options),
and then generate from there - schemas again (DTD, RNG, XSD), maybe documentation
(this would be harder I think), and authoring templates (this would potentially
be easier).

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley



From:      
 Fredrik Geers <fgeers@sdl.com>
To:      
 "dita-lightweight-dita@lists.oasis-open.org"
<dita-lightweight-dita@lists.oasis-open.org>
Date:      
 06/16/2015 10:49 AM
Subject:    
   [dita-lightweight-dita]
Tables and more
Sent by:    
   <dita-lightweight-dita@lists.oasis-open.org>

---

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