Project

Profile

Help

Bug #5494

closed

Properties of attribute nodes have internal names which change from one release to another

Added by Jai B over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
API
Sprint/Milestone:
Start date:
2022-05-18
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
Jai B
Contact person:
Jai B
Additional contact persons:
-

Description

Hi,

This very well may not be a bug but perhaps user error, but it appeared when upgrading to 2.4.0.

Have XSLT files that are used for templates for a website generating XHTML5 output.

We have some tags in them like, <ff:component src="" />, we have our namespace 'ff' set in the templates and also set with XPathOptions in order to make Saxon not complain.

After compiling the stylesheet and getting the result, we do SaxonJS.XPath.evaluate for the component elements and add them to an array of objects with the components name and the element itself.

On Saxon 2.3.0, when calling .next() on a returned element from evaluate, the node in the object returned was referenced as .kb, since 2.4.0 it is now referenced as .eb.

In the first place, I'm not sure why the names would be 'eb' or 'kb' versus something like 'childNode'.

I am passing .principalResult from SaxonJS.transform() on a sef file that was originally compiled from the XSLT sources; we cache the sef and only recompile if the XSLT has changed, while the input XML obviously would change more often.

		this.XPathOptions = {
			resultForm:'iterator',
			namespaceContext:{
				'xsl':'http://www.w3.org/1999/XSL/Transform',
				'ff':'http://www.shaped.ca/freeform'
			}
		};

...

		let ffComponentNodes = this.saxon.XPath.evaluate('//ff:component/@name',doc,this.XPathOptions);

		for (let x=ffComponentNodes.next();x!=null;x=ffComponentNodes.next()) {
			logger.log(util.inspect(x))
			ffComponents.push({
				name:x.value,
				node:x.eb // wtf? x.kb for saxon 2.3.0?? ughwtf
			});
		}

		for (let component of ffComponents) {
...
			component.node.parentNode.replaceChild(componentChunk.firstChild,component.node);
		}

I'm not sure if I'm doing something wrong, if this is an actual issue/bug but it only popped up when using 2.4.0 and jumping back to 2.3.0 resolved it; also, changing from using x.kb to x.eb also seemed to fix it.

Are these variables just the result of some sort of transpilation?

Also, I can't seem to find any information regarding this and I've searched pretty heavily. I know that JSON is an option for input in a way, although most of the references I can seem to find about this seem to imply that people are using an XSLT stylesheet to dictate how to translate JSON to XML or vice-versa.

What I want to do is a little different; I want to provide the input data for an XSLT template that would normally be XML, as JSON instead. My XSLT stylesheets are basically webpage templates with the XML input being the data to fill them out. Now that my system is all on node, I feel like I'm doing a needless step converting my data from JSON->XML before translating it, I'd like to be able to just use JSON as input but I haven't had any luck by setting sourceType: 'json' in the .transform({options})..? If this is possible is there somewhere I can find some better docs on it?

I feel like there's potentially more functionality available in SasonJS too that's not as well documented; I would love to see the documentation improved perhaps.

Previously my web platform used PHP and XSLT templates for just about everything; it seems time to perhaps use Node instead and SaxonJS seems to be my best bet for templates and so far it's mostly working great, although there's a few oddities I haven't figured out, I will likely post in the forum now that I'm signed up.


Related issues

Related to SaxonJS - Bug #5535: Improve documentation for exposed node propertiesClosedDebbie Lockett2022-05-24

Actions

Please register to edit this issue

Also available in: Atom PDF Tracking page