HelpXplain XML schema?

[Simon_Dismore]

Is the HelpXplain project file XML schema documented anywhere?

I was thinking of testing Altova StyleVision as a starting point to pre-populate projects.

Thanks for any info
Simon

[Tim Green]

Hi Simon,

The Help & Manual XML schema is fully documented in the Helpman_XML_ref.chm file, which you can find in the Help & Manual program directory. You also have the full XSD schema file in every Help+Manual project at the root level.

[Simon_Dismore]

Hi Tim

Yes, I know about Helpman_XML_Ref.chm

I was wondering whether there was something similar for HelpXplain, documenting elements like <frame> <spotlight> <calloutshape>, the <VisualElements> configuration etc.

Thanks,
Simon

[Tim Green]

Hi Simon,

Sorry, I skimmed your mail too quickly along with many other things. I'll check into this.

[Tim Green]

Simon,

I just checked and the XML used in Xplains isn't currently documented officially. It's also not formalized with an XSD, as of yet.

[Simon_Dismore]

Simon,

I just checked and the XML used in Xplains isn't currently documented officially. It's also not formalized with an XSD, as of yet.

Thanks for checking!

[Alexander Halser]

Hi Simon,
The XML format of HelpXplain is not officially documented, and we don't plan on disclosing it, either. It just doesn't make sense. An .xplain file is a zip archive that not only consists of an XML file inside, but also image files and other binary resources, together with a fully rendered preview image at full size and thumbnails of every slide. So in order to create an .xplain file manually outside HelpXplain, you'd need to reproduce all that.

I suggest you focus on our next project, which we hope to offer a beta version for quite soon (definitely before Christmas).

SnipSVG is a new image editor, meant to replace the old Impict image editor in Help+Manual. It's based on the library of HelpXplain, but is designed to edit static images only.

The beauty of this tool is (hence the name): it can save annotated screenshots in SVG format, and read them again. In other words: instead of attempting to create HelpXplain XML, create an SVG file that SnipSVG can read and edit.

That's going to be much easier.

[Simon_Dismore]

Hi Alexander

Thanks for the feedback. I think for our use case - which is mainly re-purposing/translating - we can simply replace files in the zipped xplain: there's usually a 1-to-1 equivalent, so it isn't essential to understand the XML. The goal was never to replace HelpXplain, just to scaffold input for it. If I delete all the png previews I think HelpXplain just re-creates them from the source slides.

Re: SnapSVG, I'd love to see it., particularly if...

• Resources can include separately maintained SVG documents as well as bitmap images
• Resources can be internal or external (use cases: translation, versioning, division of authoring responsibilities, CSS)
• Author has option to control resource filenames and their internal IDs
• External resources can have a relative base location (as above, and very helpful for mass changes)
• External resources can be "compiled" into the main file (by compiled I'm thinking you can merge in SVG and CSS, and base64 encode bitmaps)
• Parts of the SVG can be addressed using #fragment IDs (use case: show/hide things)
• ...and H+M and HelpXplain can address images using #fragment IDs (details here).

Best wishes
Simon