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: Re: [dita-lightweight-dita] Tables and more


This is delightful!

On tables: from my field experience, I *strongly* emphasize the power and
impact of whatever we set as the defaults. Saying "you can easily add CALS
tables back in" is damning CALS tables to a very, very niche existance
forever more. Whatever we set as the default model will be what the vast
majority of people will use and vendors will configure for.

That said, this could be mitigated by the easing the creation of
specialisations (but again, vendors will have to all be able to
dynamically configure themselves for new specialisations and only a few do
this).

I spent a long time in DITA 1.1 thinking about the two approaches you
describe and want to say that my definite preference is option 2. Ideally,
the experience should be as much like saving a template as possible. In
other words, you take any topic (including already specialised ones) (and
maybe set something at the root that tells the editor to open up the model
into a 'specialisation mode') and then you can create a target structure.
Then you save, hit 'go', and then you have a 'template' that other authors
can then be contrained by.

IMHO, mimicking the logical flow of more common tools will vastly improve
adoption of this ability of DITA.

Noz


On Tue, June 16, 2015 9:52 pm, Michael Priestley wrote:
> 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
>


-- 
Noz Urbina
Content Strategist and Founder, UrbinaConsulting.com

Author, "Content Strategy: Connecting the dots between, business, brand,
and benefits" http://thecontentstrategybook.com


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