Exposing the C14N functionality

[shunkica]

I have been tinkering with this project, trying to figure out how it works, by exposing the C14N functionality of libxml2.

I have added this function:

export function canonicalize(document: XmlDocument): string {
    const docTxtPtr = libxml2._malloc(4);
    const result = xmlC14NDocDumpMemory(document._ptr, 0, 0, 0, 0, docTxtPtr);
    if (result < 0) throw new Error('Failed to canonicalize XML');
    const txtPtr = libxml2.getValue(docTxtPtr, 'i32');
    if (!txtPtr) throw new Error('Failed to get canonicalized XML');
    const canonicalXml = libxml2.UTF8ToString(txtPtr, result);
    libxml2._free(txtPtr);
    return canonicalXml;
}

And this simple test:

const xmlString = '<root><child attr="value">text</child></root>';
const doc = XmlDocument.fromString(xmlString);
const canonical = canonicalize(doc);
doc.dispose()

However, the error Failed to get canonicalized XML is thrown here.

The result of xmlC14NDocDumpMemory is 45 as expected, but I can't figure out how to get the output.

Here is the commit: shunkica/libxml2-wasm/commit/5a60a39

[jameslan]

Yes I can reproduce this. It seems that this memory in C doesn't map to the js buffer HEAPU8/HEAP32 for some reason.

[jameslan]

The problem is in the following snippet:

import {
    xmlC14NDocDumpMemory,
} from './libxml2.mjs';
import type { XmlDocument } from './document.mjs';
import moduleLoader from './libxml2raw.mjs';

const libxml2 = await moduleLoader();
export function canonicalize(document: XmlDocument): string {
    const docTxtPtr = libxml2._malloc(4);
    const result = xmlC14NDocDumpMemory(document._ptr, 0, 0, 0, 0, docTxtPtr);

moduleLoader is a function that creates a WASM module. libxml2.mts calls moduleLoader to create one, and exports its functions. Let's call this instance of libxml2 global.
In your code, you created a new instance, by calling moduleLoader, and let's call this instance local.

So in this code snippet, xmlC14NDocDumpMemory as well as the DOM objects are from the global instance(because you parsed them using libxml2-wasm functions).
When const result = xmlC14NDocDumpMemory(document._ptr, 0, 0, 0, 0, docTxtPtr); is executed, everything is stored in the memory of global instance.

However, you are allocating space in the local instance to receive the pointer. That's why it failed.

[shunkica]

Thank you for taking the time to analyze this issue for me.

Here is my updated code: shunkica/libxml2-wasm/tree/c14n

Would you be open to adding the c14n functionality to this library?

Additionally, would you be open to adding functionality which maps a DOM Document type object to a libxml2 Document using direct structure mapping?

Essentially re-materialize the DOM inside libxml2 without going through a string by walking the DOM and creating libxml2 nodes one-by-one.

[jameslan]

I'm definitely open to adding c14n functionality. For the interface design, I think it would make sense to implement it as two methods on the XmlDocument class, following a similar pattern to XmlDocument#save and XmlDocument#toString - one method for flexibility and another for convenience.

Regarding the second feature you mentioned, I'm not entirely sure I understand what you have in mind. Could you share a concrete example of how this would work?

[shunkica]

@jameslan
This is what I had in mind: DOM Document to libxml2

Something like the domDocToLibXmlDoc function.

Could be like XmlDocument.fromDomDoc()