TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
There is a lot of myth/folklore that has been spread around about the XML underpinnings in Flare. I just don't think that a lot of people understand what it is that we are doing, or why.
The MadCap Flare source files are absolutely well-formed and valid XML, but they are validated against two XML SCHEMA not one. In this hybrid approach all visible content (headings, paragraphs, lists, tables, etc.) validate against the W3C SCHEMA for XHTML. Because of this most people jump to the incorrect conclusion that Flare is simply an XHTML editor. This is grossly incorrect as if they looked a little more closely they would realize that the very second line of the XML document calls out a secondary MadCap SCHEMA via an XML namespace declaration. Why the second SCHEMA? XHTML doesn't have any concept of conditional markers, variables, reusable content snippets, etc. so we augment the XHTML SCHEMA with the MadCap SCHEMA to add that functionality.
Many have asked why we did it this way instead of simply writing our own proprietary SCHEMA for everything. It would have been much easier for us to do just that, but then we would be locking up customers content in a proprietary fashion like a lot of other tools out there. Our goal was to provide maximum single-source capabilities, but in a method that never locks up the customer content in a proprietary fashion. If people want to kick our products to the curb next year, then any tool that can read XHTML can reuse the content they worked so hard to develop.
As to having acces to the XML in addition to our visual editor that was just granted a patent for how we make document structure available via our visual structure bars, Flare also has a great raw XML editor with line wrapping, line numbering, and element color coding.
I hope that this helps,
Mike Hamilton
MadCap Software
________________________________________
From: techwr-l-bounces+mhamilton=madcapsoftware -dot- com -at- lists -dot- techwr-l -dot- com [techwr-l-bounces+mhamilton=madcapsoftware -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Porrello, Leonard [lporrello -at- illumina -dot- com]
Sent: Tuesday, April 12, 2011 2:57 PM
To: 'beelia -at- pacbell -dot- net'
Cc: TECHWR-L Writing; Chris Gooch
Subject: RE: DITA useful for translation?
Thanks, Bee, for the clarification. I know MadCap talks about Flare being "XML-based," but I haven't been able to understand what that really means, and this leads me to think that it is just marketing doublespeak. In contrast, the XML H&M creates from WYSIWYG is well-formed, and you can also edit the XML directly. Do you know, is there any way to get to Flare's alleged XML? Is it well-formed (a somewhat redundant question since if it isn't well-formed, it isn't XML)?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
