Lightweight DITA SC

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

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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php