When it comes to redefining HDITA tags as custom elements, the “easy” way would be customized built-in elements (<section is="section-example”>), which extend an existing tag in HTML5. These are pretty easy to implement and light. Autonomous custom elements (<section-example>) look “cooler” and closer to XDITA. I think Don and Mark have more experience with these than me… but I know they do not need stylesheet support. Browsers (Safari needs to catch up soon) will process them as valid HTML even without sophisticated DOM/CSS rules. Now, talking about MDITA, I can rescue and share with the subcommittee the mapping of DITA elements I made last year. All of that has already been implemented and tested in Jarno’s Markdown plug-in, except for the conref thing based on G. Torikian’s Github-Liquid homage to DITA ({{ site.data.conrefs.steps.turn_off_machine }}). Happy to do this over email or in side meetings….
Carlos
-- Carlos Evia, Ph.D. Director of Professional and Technical Writing Associate Professor of Technical Communication Department of English Center for Human-Computer Interaction Virginia Tech Blacksburg, VA 24061-0112 (540)200-8201
Sounds like a plan! Should we try through
email, or have some side meetings? Who else is interested?For the HDITA mappings, I've got a couple
of concerns with an element approach: - how top-heavy the declarations
will make the file (eg if we have five lines of _javascript_ per new element,
and a specialization with twenty new elements in it, that's 100 lines of
freight - potentially enough to double the size of a small topic) - whether we need to care about
their specialization architecture, which seems to be mostly extension rather
than restriction, and would also mean that we don't get new element names - can we get decent fallback behavior
without stylesheets? or will this approach have a hard dependency on stylesheet
instructions for each new element? That said, I see the attraction of an
element-based approach, and if we can make it work and it has value we
can demonstrate then I think it looks cooler and bridges to XDITA more
clearly.For MDITA, I think we just need to take
a hard look at what the dependencies are for each extension we propose.
Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestleyFrom:
Carlos Evia <cevia@vt.edu>To:
Michael Priestley/Toronto/IBM@IBMCACc:
dita-lightweight-dita@lists.oasis-open.orgDate:
05/26/2016 09:31 AMSubject:
Re: [dita-lightweight-dita]
Specialization model - elements and attributesSent by:
<dita-lightweight-dita@lists.oasis-open.org> I feel like a bad student because I missed our last meeting
and will miss the next one (Memorial Day in the US).Should we/I work on the new mappings of HDITA and MarkDITA?Carlos--- Carlos Evia, Ph.D.Director of Professional and
Technical WritingAssociate Professor of Technical
CommunicationDepartment of EnglishCenter for Human-Computer InteractionVirginia TechBlacksburg, VA 24061-0112(540)200-8201 On May 25, 2016, at 9:46 PM, Michael Priestley <mpriestl@ca.ibm.com>
wrote:I wanted to draw attention to my slides
from the Lightweight DITA pre/overview at CMS/DITA North America (updated
with slides borrowed from my joint presentation with Carlos Evia and Jenifer
Schlotfeldt).
It's got what I believe to be an up-to-date view of the proposed template
specialization model, with a simple example http://www.slideshare.net/mpriestley/lightweight-dita-a-preoverview
The technical overview (as opposed to business case/scenarios) starts on
slide 22.
The template specialization overview is on slides 30-35.
Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley
|