Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracing #2

Open
caseydawsonjordan opened this issue Feb 26, 2014 · 3 comments
Open

Tracing #2

caseydawsonjordan opened this issue Feb 26, 2014 · 3 comments

Comments

@caseydawsonjordan
Copy link

What would need to be done to get tracing working with SaxonCE?

I have a need to be able to know exactly what source node produced what output node and ideally what Instruction caused it.

I'd be happy to do the work to make this function if I had some guidance.

Cheers

@pgfearo
Copy link

pgfearo commented Feb 27, 2014

Have you looked at the existing trace features in Saxon-CE? Note that when using trace (logLevel=FINEST) its quite easy to overwhelm the logging capabilities of the browser for non-trivial XSLT: Trace features are documented at the following link;
http://www.saxonica.com/ce/user-doc/1.1/index.html#!coding/logging

@caseydawsonjordan
Copy link
Author

Hi Phil,

From what I can tell the existing trace features in CE either don't work or
don't work as I expected them to. I played with them a little and didn't
get the results I was expecting.

One issue is the ComplexContentOutputter alters the order in which output
happens, or more specifically, it caches events like startElement() and
then later flushes them when it needs to. This means that the actual
context in the document will have changed when a start element is actually
flushed.

Is tracing appropriate for my use case?

On Thu, Feb 27, 2014 at 4:46 AM, Phil Fearon [email protected]:

Have you looked at the existing trace features in Saxon-CE? Note that when
using trace (logLevel=FINEST) its quite easy to overwhelm the logging
capabilities of the browser for non-trivial XSLT: Trace features are
documented at the following link;
http://www.saxonica.com/ce/user-doc/1.1/index.html#!coding/logging

Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-36225822
.

Casey Jordan
easyDITA a product of Jorsek LLC
"CaseyDJordan" on LinkedIn, Twitter & Facebook
(585) 348 7399
easydita.com

This message is intended only for the use of the Addressee(s) and may
contain information that is privileged, confidential, and/or exempt from
disclosure under applicable law. If you are not the intended recipient,
please be advised that any disclosure copying, distribution, or use of
the information contained herein is prohibited. If you have received
this communication in error, please destroy all copies of the message,
whether in electronic or hard copy format, as well as attachments, and
immediately contact the sender by replying to this e-mail or by phone.
Thank you.

@michaelhkay
Copy link
Member

Tracing provenance in this way (that is, linking nodes in the output to nodes in the input, and to instructions in the styelsheet) is quite a challenge. The XML IDEs such as oXygen and Stylus Studio do it, I believe, but there's no underlying support in Saxon. And the pressure is in the direction of reducing code size not increasing it. (OK, it could be in the tracing/debug version of the product only, but that still doesn't make it zero-overhead).

As you point out, it's difficult to associate nodes in the result tree with events notified to the TraceListener because of the latency introduced by the ComplexContentOutputter (which is there primarily to enable namespace fixup to work correctly). I'm not sure how the debugger IDEs get around this problem, though I do remember discussing the problem with them at the time. It's also true that we don't have an obvious place to insert extra code in the output pipeline for CE where we are doing insitu update of the HTML DOM.

I'd be happy to do the work to make this function if I had some guidance.

It's open source, so feel free to experiment and tell us the results. I don't think it's possible to offer suggestions on how this might work without actually trying things out. If you do want to do any development that might be fed back into the product, do give some thought to its testability; that's the part which potential contributors often forget about, and we've been known to reject contributions because we don't know how to test them.

Regards,

Michael Kay
Saxonica

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants