Re: [dita-lightweight-dita] Full DITA compatibility

["Noz Urbina" <noz.urbina@urbinaconsulting.com>]

Hi Fredrik,

I couldn't make the Monday meeting but a similar similar thoughts have
been coming to my mind.

My feeling is that the heart of DITA, the thing that really is needed in
all types of communication is only:
modules - delineated blocks of reusable content
shortdesc - to add progressive disclosure to modules
maps - a way to put them back together and apply contextual metadata
conref - granular reuse
(optionally, conkeyref - contextual granular reuse)

If we can bring those things over - admitting loads of people won't bother
with conkeyref - then I think we have what we need for wider use.

Semi-related thought from my own area: I'm focused on marketing/eCommerce
use cases and I'm finding that even relatively simple concepts like the
difference between topics and sections is flummoxing me. I have been
trying to do some content marketing work in DITA and doing my best to be
creative in a DITA-based system (and I'm not stranger to DITA editors).
Where I get stuck is when I make something a section and then realize it's
got to get relocated in the map or wants a short description and then I
realize I have to switch it over to topic. This is deeply disruptive to
the creative process.

I think that one of the main challenges is that lightweight DITA needs to
"meet in the middle" with certain non-techcomm process realities. One
example of which is that outside very disciplined areas/companies, people
just don't plan their content architectures that much. They want
reusability and modularity and portable architecture (maps) but asking a
marketing team (for example) who has to put together 3 content pieces in
72hrs (and in the case of print will need careful visual tuning) there are
aspects of the spec like this which seem extremely simple if you're from a
background of more riguous or linear creation processes, but in the more
freeform environments post real challenges. I feel there has to be a
sliding-scale of complexity, even within lightweight DITA for people who
want to use it as "HTML with modules" for people who want to have planned
architectures and proper reuse strategies and governance. I'd vote to set
the entry bar low and then lower it 5 more times...

If that means sacrificing extremely easy transition back to full DITA I
think that's acceptable losses. Although what couldn't we just put back
into a DITA generic topic? Sharing only domain specialisations (as opposed
to structural) might help?

- Noz


On Thu, May 7, 2015 5:17 pm, Fredrik Geers wrote:
> The call we had on Monday got me thinking about the DITA compatibility.
> Should it be possible to switch to the full DITA by just switching the
> doctype?
> What is the goal of this subcommittee? To create the best possible subset
> of DITA? Or to create something that borrows the best concepts from DITA
> and puts it in a lightweight format? If it is the latter, it should be
> possible for us to drop direct compatibility to allow for a simpler
> solution. I feel that if we answer this now, it would set a better context
> for all following discussions.
>
> Also when we're talking about simplicity, we need to think about what
> makes a document model simple. What are properties that make a model
> simple? Is simplicity something with the greatest amount of freedom? Or is
> simplicity a model that is as restrictive as possible, relieving the
> author from making certain choices? Or do we mean simplicity for
> processing the content?
>
> Markdown is an example where simplicity is accomplished through offering
> freedom. As long as you know the vocabulary, you can write your content.
> No need to worry about if one element is allowed in another element - all
> types of content are generally allowed everywhere.
> The exact opposite of Markdown, but what still could be considered simple,
> is a very restrictive xml schema. Because of the restrictions, it becomes
> clear what to do, and writing documents is almost like filling in a form.
>
> The current full DITA standard is from an authoring perspective neither of
> above examples. It does not offer enough freedom to just "tag" your
> content as in Markdown, though it is not restrictive enough to give real
> clarity in how it should be used. Do we want to attempt to improve on
> this? And can we do something about that if we're keeping the full DITA
> compatibility?
>
> Fredrik Geers | Product Owner SDL LiveContent Create/SDL Xopus | SDL |
> (t) +31 (0)20 201 0500 | (e) fgeers@sdl.com
>
>
>  [http://cdn.sdl.tridion.sdlproducts.com/static/corporate/SDLlogo2014.png]
> <www.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