[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [dita] Comments on 06-05-2017 LwDITA Working Draft 17 PDF
Meant to send this to the list. My bad. Best,
Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) -------- Forwarded Message --------
Hi, Stan -- Questions and comments below. Best,
Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 6/13/2017 9:41 AM, Dr. Stanley
Doherty wrote:
<kje>Clarification -- "the relatively closed environments that have demonstrated little interest in building interoperable solutions" -- are these the companies with infrastructures based on Git and Attlassian? Or Git and Attlassian?Hi -- The committee note reads better with each draft . . . my compliments to all the cooks!! A few comments on the PDF: Pg-8 - "Why Lightweight DITA?" This is still very XML- and publishing-centric. Companies that have made significant investments in engineering infrastructure based on GIT or Atlassian want nothing to do with XML or DITA because these are relatively closed environments that have demonstrated little interest in building interoperable solutions. Many engineering groups and most technical marketing organizations, especially the agile ones, have written off XML and DITA. LwDITA is DITA's first attempt to build bridges toward de facto engineering and Marketing standards. I recommend emphasizing the role that the non-XML flavors of LwDITA might play in building collaborative authoring environments. We (OASIS) are playing catch-up . . . it can't hurt to come clean about that. Can you suggest changes to this topic? It was added late to the draft, mainly worded by Michael Priestley, and it does need more attention.</kje> <kje>This topic is another late addition. I added it to ensure that we had a topic for each of the three core goals of LwDITA that are listed in "3 What is Lightweight DITA?". Can you augment your comments? In particular:Pg-9 - "Simplified Structured" Just a thought -- if we fast-forward 12-18 months, we'll be supporting DITA 1.3, DITA 2.0, and LwDITA concurrently in the market. LwDITA simplifies things along one axis, but we should anticipate some flak about our making the collective, XML-based publishing world more complex by virtue of distributing multiple versions of the DITA standard. Pg-9 - Support for non-XML formats Love it. Pg-10 - "Development of LwDITA tools and applications" This is an important section. Some additional thoughts to consider: - Vendors or developers of lightweight editors could choose to extend support to non-XML LwDITA formats. - Vendors of content management systems could extend data management and processing support. - Vendors of engineering management frameworks (Atlassian, GitHub) could develop LwDITA-compatible plug-ins and extensions to content developers could author LwDITA-compatible content from within these framework environments. FWIW . . .
<kje>Of course you can reference LwDITA topics from a DITA 1.3 map. We should brainstorm use cases for LwDITA maps. Certainly folks working in a LwDITA-only environment (or tool) will need a mechanism to aggregate content. Also, people using XDITA who want a simpler map experience. And all folks using or authoring HDITA and MDITA.</kje>Pg-12 - "Elements in the LwDITA map" If I have built my heavy-weight publishing pipeline around DITA 1.3 maps, will I be able to reference LwDITA topics from my DITA 1.3 maps? I would guess that many companies might adopt LwDITA topics long before they adopt LwDITA maps. Are LwDITA maps only relevant in a LwDITA-only environment? Pg-13 - "Subset of reuse mechanisms" Sometimes the references to LwDITA supports this or LwDITA does not support that are a little confusing relative to the specifics of what XDITA, MDITA, and HDITA support. The sentence "The content reference mechanism is not available in MDITA" suggests that it IS available in XDITA and HDITA? Perhaps being explicit about MDITA and HDITA support for XDITA features would help. Pg-16 - "Audience for HDITA" Forgive my ignorance -- are there, realistically, any real-world content development tools that produce a flavor of HTML5 that would pass for HDITA? The Marketing and Support groups with whom I have been working for many years use MS Office products or captive CMSs to author content. Are there examples of popular, non-XML authoring tools that produce clean HTML5? If so, perhaps a guarded reference to them would make this more appealing. UXD and software developers do not produce HTML content. Mocks - yes. Content - no. Can HDITA topics be rendered in a browser? If so, could to insert a <topicref> to an HDITA web page URI? Pg-18 - "Audience for MDITA" Might be useful to note that API/REST development frameworks have adopted various flavors of Markdown as their default markup (apiary, Swagger, RAML, MuleSoft, API Blueprint). Writing add-ins that converted these API data structures directly into LwDITA could be the most compelling argument to Engineering VPs to consider adopting MDITA (without XDITA necessarily). Lead with MDITA, keep Baby (XDITA) in the corner. :-) Pg-20 - "Authoring cross-format content with LwDITA" Hmm . . . still not clear to me that I could not sit in a DITA 1.3 map and <topicref> XDITA, MDITA, and HDITA topics. The reference to "DITA map" in teh first bullet is ambiguous. DITA 1.3 map? XDITA map? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]