Wrong output at processing

[javorosas]

Hi. First of all, thank you for your effort. It's really nice to find an XSLT processor with no dependencies.

I'm getting different outputs from processing the same xml/xslt using the library I want to move away from (libxslt) and this one. I'm pretty sure the one libxslt provides is the correct one because I have compared it with some tools developed in Java.

What I'm expecting looks like this:

||3.3|1234|2018-06-03T16:16:36|02|1234567890|25862.07|MXN|1|30000.00|I|PUE|83240|ASS010101A12|Aligator Service, SAPI|601|DCS030303W09|Defenseless Canary, S.A. de C.V.|G03|43211508|DELL123|3|EA|Laptop DELL XPS 13|8620.689655|25862.07|25862.07|002|Tasa|0.160000|4137.93|0.00|002|Tasa|0.160000|4137.93|4137.93||

And what I'm getting is the exact same string but with 3 additional pipes at the beginning.

|||||3.3|1234|2018-06-03T16:16:36|02|1234567890|25862.07|MXN|1|30000.00|I|PUE|83240|ASS010101A12...

I set up a repo with a unit test so you can easily reproduce it: https://github.com/javorosas/test-xslt

If you need me to add the libxslt implementation to the repo, please let me know.

Thanks in advance.

[johanneswilm]

Hey @javorosas, with any such issue, if you have done any JavaScript programming, you will most likely be able to find the issue before me because this is something you really need and you know the input you fed into it. The library is working as is for me and there is noone financed to work on this library, but contributions are welcome.

[johanneswilm]

@javorosas I have not added jest testing to the repo so feel free to add your tests there as well (by means of a PR). I do think though that you probably should be hunting down the bug yourself.

[edamazzio]

I'm having exactly the same issue with exactly the same xslt (Electronic Invoicing Mexico) @javorosas. How did you managed to solve this issue? Can you share what you did?

I noticed that if you do not include the "VehiculoUsado" stylesheet, it outputs the expected string. This is because (as you probably already noticed) there is also a starting pipe and ending pipes in this stylesheet, and as there is probably no "complemento de vehículo usado" in the invoice, it just comes out empty (|||).

[javorosas]

@edamazzio I didn't. I'm still using libxslt, partly because I found out it runs significantly faster. You can also consider using Facturapi for your electronic invoicing needs in Mexico.

Btw, that's a very interesting observation, but still my point remains valid. Why do all other libraries ignore this part and don't return any additional pipes for empty elements? Should this library do the same? Maybe it's a spec @johanneswilm could consider adding (if he's interested in doing so, of course).

As I said, I don't think I'll move away from libxslt any time soon. So yeah, good luck to you both.

[johanneswilm]

@edamazzio @javorosas Have either of you tried to compile libxslt/libxml to webassembly? I am currently considering whether it would make sense to try to do that instead of continuing this library. Libxml seems to be compile with emscripten already [1] and emscripten now has a webassembly output configuration so it seems like that could work.

[1] https://github.com/emscripten-core/emscripten/wiki/Porting-Examples-and-Demos

[edamazzio]

@johanneswilm Your suggestion seems interesting, however, I'm not trying to use this implementation in a web browser, I'm trying to use your library in a server-side application that runs based on javascript.

And @javorosas Thank you for your suggestion. Facturapi seems much easier than the one I'm using right now.

Best wishes to both

[johanneswilm]

@edamazzio Right that's probably the case of 99% of the users of this library given that browsers actually do have libxslt available. As far as I an tell, nodejs also supports webassembly. I haven't investigated this much as I just translated this lib several years before we actually will get to use it. That's why I'm wondering if others have tried that.