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

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

I think we need titles and IDs but we need to keep bodydiv and ph (for
conrefing). The entire point of a section would be to have a heading. In
fact, section can be considered simply "the heading marketer that takes
you to the next heading/end".

Not being by any means fluent with the HTML5 spec, if people are going
to/from HTML 5 they can use nesting/chunk to decide what level in their
hierarchies they want to get converted to articles, no? If so, I think
we're losing very little in terms of conversion back and forth.




On Fri, May 8, 2015 8:27 pm, Michael Priestley wrote:
> I'm thinking the MVS (minimal viable spec) will need:
>
> Structure:
> - maps (nesting topicrefs only - no reltables)
> - topics (title, shortdesc, sections, blocks (paragraph, lists, table,
> image, audio, video))
>
> Capabilities/attributes:
> - keyref on ph for managing variable text
> - conref on blocks for higher-level reuse (not sure if we need conkeyref)
> - props on blocks for conditional processing
>
> Maps can then be used for:
> - navigation (with href on topicref)
> - variable management or taxonomies (with keys)
>
> I think the issue with sections vs topics can be mapped to the issue of
> articles vs sections in HTML5. We should borrow their guidance and make it
> their problem. Otherwise, we could consider making section abstract and
> only usable for specializations (where they are essential) - but at the
> cost of a clear mapping to HTML5.
>
> Re breaking compatibility with full DITA: I'm open to the possibility, IF
> there is a compelling requirement. Full processing compatibility buys us a
> lot in terms of tool reuse and infrastructure integration. If we break
> that compatibility, it will take a big chunk out of lightweight DITA's
> value proposition. It would need to be replaced by an even bigger chunk of
> some new value. I don't think this is a discussion that makes any sense in
> the abstract.
>
> Is there a concrete example of where we would want to break compatibility?
> If we take markdown as an example - what could you author in markdown that
> wouldn't be valid in DITA?
>
> The only examples I can think of right now are:
> - need an id for the topic
> - need to start with a title
>
> Would we be prepared to say that lightweight DITA topics no longer need
> titles or ids, in order to achieve a markdown-like level of freedom? For
> what it's worth I definitely want titles and ids :-)
>
> Michael Priestley, Senior Technical Staff Member (STSM)
> Enterprise Content Technology Strategist
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/michael-priestley
>
>
>
> From:   "Noz Urbina" <noz.urbina@urbinaconsulting.com>
> To:     "Fredrik Geers" <fgeers@sdl.com>
> Cc:     "dita-lightweight-dita@lists.oasis-open.org"
> <dita-lightweight-dita@lists.oasis-open.org>
> Date:   05/07/2015 12:05 PM
> Subject:        Re: [dita-lightweight-dita] Full DITA compatibility
> Sent by:        <dita-lightweight-dita@lists.oasis-open.org>
>
>
>
> 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