OtherNamespace content

[JakobVogelsang]

Each element in the SCL can have either an array of Private, Text or xs:any child element that are from ##other namespace. From what I have understood in discussion primarily with @ca-d

• we cannot really compare the information in those elements, as we cannot reliably understand the semantics.
• we cannot compare the inner string either
• we need to normalize those elements and compare this

The open questions I have here is:

• what are the options to normalize those elements. Is there a solution for this we can use libxml2 or do we need to reinvent the wheel here
  @danyill could you share some of the insights you got of this topic

[ca-d]

There is a libxml2 c14n function suite which may be used like this, we could wrap that up in some wasm with emscripten the way we do with schema validation right now.

There is no pure js way to canonicalize XML according to some stack overflow question from 2012

[JakobVogelsang]

The link to the stack overflow discussion is quite old. I would give it another shot and see what is available today. By doing so, I have found that there are two types of canonicalization types - inclusive and exclusive. I wonder which one we need here. @ca-d what would you say and way?

[JakobVogelsang]

I try it myself: "Exclusive canonicalization finds out what namespaces you are actually using (the ones that are a part of the XML syntax) and just copies those. It does not look into attribute values or element content, so the namespace declarations required to process these are not copied. ... will insure the signature verifies correctly every time, so it is required when you need self-signed structures that support placement within different XML contexts.
" (see here http://anilsaldhana.blogspot.com/2009/07/exclusive-versus-inclusive.html)

It sounds to me like we want to go with this :) What do you think?

[danyill]

I agree.

…

On Sat, 17 Jun 2023, 08:33 Jakob Vogelsang, ***@***.***> wrote: I try it myself: "Exclusive canonicalization finds out what namespaces you are actually using (the ones that are a part of the XML syntax) and just copies those. It does not look into attribute values or element content, so the namespace declarations required to process these are not copied. ... will insure the signature verifies correctly every time, so it is required when you need self-signed structures that support placement within different XML contexts. " (see here http://anilsaldhana.blogspot.com/2009/07/exclusive-versus-inclusive.html) It sounds to me like we want to go with this :) What do you think? — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFEXX55ZJMAEUSQI5BVH2LXLS7H5ANCNFSM6AAAAAAX3MMEE4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ca-d]

I don't quite understand yet, the difference between these two seems to have to do with the "scope of the signature", so I understand the document @JakobVogelsang linked to mean oxygenXML's exclusive canonicalisation looks at the signature that you intend to sign the document with and only canonicalises the parts of the document defined in namespaces within the scope of the signature.

Since we don't have a signature, I looked at the libxml2 c14n documentation instead, where the xmlC14NMode at the top seems to indicate support for the new C14N spec version 1.1 which does not distinguish between inclusive and exclusive mode, something that might be worth looking into.

If we stick with the old C14N spec version 1.0 (despite known issues) it sounds to me intuitively like the original ("inclusive") version of the standard would be the way to go, since we precisely want to canonicalise XML content of namespaces that are not known to us: Private elements containing arbitrary XML and/or elements from foreign extension namespaces for which we have no schemas. Maybe I misunderstood something and got on the wrong track?