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] Comments - Lightweight DITA: An Introduction uploaded


Hi Stan,

Thanks for the feedback!
My responses follow:

PDF/5: In the Note, would it not be better to say, "Please note that details WILL change . . . "

CE: I say we keep "might." What if nothing changes and people come demanding changes? ;-)

PDF/6: The "extended profile" definition makes sense, but precludes PanDoc -- which isn't really a variant of GFM.

CE: Not sure what you are asking for here. The extended profile definition does not mention Pandoc and it doesn't mention MarkdownExtra either... it includes them in the "specific Markdown variants" comment. Do we need to list them here?

PDF/7: The definition of "slug" needs more explanation. Is it a URL-friendly version of an XDITA topic title? HDITA? MDITA? Perhaps a quick example might help.

CE: The example for slug is on page 20. The terminology is only throwing a brief definition. Do we need more?

PDF/8: Still feels to me that we need to be more direct about selling LwDITA to non-XML shops. LwDITA does make content in additional authoring formats available to the same XML-based publishing pipeline that DITA 1.3 uses (the ecosystem). These additional authoring formats (XDITA, MDITA, and HDITA) do not interoperate with existing non-XML publishing pipelines. For authoring communities NOT interested in working in an XML-based ecosystem, LwDITA is of limited appeal.

CE: I don't think the Committee Note has the purpose of selling LwDITA to people outside geeky/early adopter circles. We can do that selling jobs in other information products/presentations/webinars (and we have been doing it)
PDF/10: Suggest adding RST to the list of possible future mappings.

Devils advocate question: We call LwDITA markup "structured" because it is validated (ultimately) by an XML parser. If I put unsupported markup into an MDITA or HDITA document, the parser will invalidate it -- yes?

CE: It will in some cases, and those are detailed in the forthcoming spec's processing expectations.

PDF20: The sentence "The MDITA core profile aligns with the GitHub Flavored Markdown Spec" is a little squooshy. Does "align" mean that 100% of the markup in the GFM spec (including all the whitelisted HTML markup) is supported by MDITA or does "align" mean that MDITA markup is consistent with some subset of the GFM spec? It's an interoperability clarification. Will every valid GFM topic work in LwDITA? PDF/28 ditto.

CE: We are not promising 100% GFM compatibility. Do we need a better word?

PDF/21: Still a bit confused about the usefulness of MDITA maps. Can I reference them from an XDITA map? build them alone?

CE: The idea is that MDITA maps will act like XDITA maps.
--Â
Carlos Evia, Ph.D.
Associate Professor of Communication
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201



On Thu, Sep 13, 2018 at 11:44 AM Dr. Stanley Doherty <stan@modularwriting.com> wrote:
Hi --

Commendable work here . . . this reads better each time I revisit it.

Stan
---------------------------------------

A few comments on the PDF posted yesterday:

PDF/5: In the Note, would it not be better to say, "Please note that details WILL change . . . "

PDF/6: The "extended profile" definition makes sense, but precludes PanDoc -- which isn't really a variant of GFM.

PDF/7: The definition of "slug" needs more explanation. Is it a URL-friendly version of an XDITA topic title? HDITA? MDITA? Perhaps a quick example might help.

PDF/8: Still feels to me that we need to be more direct about selling LwDITA to non-XML shops. LwDITA does make content in additional authoring formats available to the same XML-based publishing pipeline that DITA 1.3 uses (the ecosystem). These additional authoring formats (XDITA, MDITA, and HDITA) do not interoperate with existing non-XML publishing pipelines. For authoring communities NOT interested in working in an XML-based ecosystem, LwDITA is of limited appeal.

PDF/10: Suggest adding RST to the list of possible future mappings.

Devils advocate question: We call LwDITA markup "structured" because it is validated (ultimately) by an XML parser. If I put unsupported markup into an MDITA or HDITA document, the parser will invalidate it -- yes?

In general -- love the examples. Thank you.

PDF20: The sentence "The MDITA core profile aligns with the GitHub Flavored Markdown Spec" is a little squooshy. Does "align" mean that 100% of the markup in the GFM spec (including all the whitelisted HTML markup) is supported by MDITA or does "align" mean that MDITA markup is consistent with some subset of the GFM spec? It's an interoperability clarification. Will every valid GFM topic work in LwDITA? PDF/28 ditto.

PDF/21: Still a bit confused about the usefulness of MDITA maps. Can I reference them from an XDITA map? build them alone?

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



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