How to debug XML processing

How to debug XML processing

[stephleg]

Hello,

After reading "Getting Web Content and pdf-Output from One Source" by Thomas A. Schmitz, i'm trying to use the same method to build a PDF file from a HTML one. But i quickly found that when something doesn't work as expected, it's pretty hard to debug because it's hard to tell if the error come from the environment file, the lua code or something else.

So are there some useful tricks to debug this kind of processing besides the \enabletrackers command? Especially is there a way to view the generated ConTeXt code after the macro expansion?

Thank you.

Regards,
Stéphane.
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: How to debug XML processing

[Thomas A. Schmitz]

On 10/18/2013 03:22 PM, stephleg@free.fr wrote:
> Hello,
>
> After reading "Getting Web Content and pdf-Output from One Source" by
> Thomas A. Schmitz, i'm trying to use the same method to build a PDF
> file from a HTML one. But i quickly found that when something doesn't
> work as expected, it's pretty hard to debug because it's hard to tell
> if the error come from the environment file, the lua code or
> something else.
>
> So are there some useful tricks to debug this kind of processing
> besides the \enabletrackers command? Especially is there a way to
> view the generated ConTeXt code after the macro expansion?
>
> Thank you.

Let me put it this way: if there is a way, I don't know about it. You're 
right that debugging becomes more complex because there are more layers 
of complexity involved. OTOH: many editors can validate xml as you type 
(I don't know of any that does the same for TeX input), so at least you 
know when your source should compile. And one tip (something I have 
started too late): put your lua code in a separate file and call it from 
within your TeX environment, that way, context's error messages become 
more precise.

Good luck!

Thomas
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: How to debug XML processing

[Aditya Mahajan]

On Sat, 19 Oct 2013, Thomas A. Schmitz wrote:

> On 10/18/2013 03:22 PM, stephleg@free.fr wrote:
>> Hello,
>> 
>> After reading "Getting Web Content and pdf-Output from One Source" by
>> Thomas A. Schmitz, i'm trying to use the same method to build a PDF
>> file from a HTML one. But i quickly found that when something doesn't
>> work as expected, it's pretty hard to debug because it's hard to tell
>> if the error come from the environment file, the lua code or
>> something else.
>> 
>> So are there some useful tricks to debug this kind of processing
>> besides the \enabletrackers command? Especially is there a way to
>> view the generated ConTeXt code after the macro expansion?
>> 
>> Thank you.
>
> Let me put it this way: if there is a way, I don't know about it. You're 
> right that debugging becomes more complex because there are more layers of 
> complexity involved. OTOH: many editors can validate xml as you type (I don't 
> know of any that does the same for TeX input), so at least you know when your 
> source should compile. And one tip (something I have started too late): put 
> your lua code in a separate file and call it from within your TeX 
> environment, that way, context's error messages become more precise.

I find it difficult to wrap my head around the XML processing details, 
mainly because I don't understand how XPATH works (there are subtle 
difference between XPATH tutorials that I find online and ConTeXt 
implementation of it). I find it easier to:

1. Keep the data as an XML source file and create a RNG schema to validate 
it.

2. Trasform XML into LUA tables. I use the lxml library (that comes with 
ConTeXt) to do this translation.

3. Format the LUA data using CDL (ConTeXt Lua Document).

This way, the parsing is separate from formatting and it is easy to verify 
both parts independently.

Aditya
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: How to debug XML processing

[Hans Hagen]

On 10/19/2013 9:41 PM, Thomas A. Schmitz wrote:
> On 10/18/2013 03:22 PM, stephleg@free.fr wrote:
>> Hello,
>>
>> After reading "Getting Web Content and pdf-Output from One Source" by
>> Thomas A. Schmitz, i'm trying to use the same method to build a PDF
>> file from a HTML one. But i quickly found that when something doesn't
>> work as expected, it's pretty hard to debug because it's hard to tell
>> if the error come from the environment file, the lua code or
>> something else.
>>
>> So are there some useful tricks to debug this kind of processing
>> besides the \enabletrackers command? Especially is there a way to
>> view the generated ConTeXt code after the macro expansion?
>>
>> Thank you.
>
> Let me put it this way: if there is a way, I don't know about it. You're
> right that debugging becomes more complex because there are more layers
> of complexity involved. OTOH: many editors can validate xml as you type
> (I don't know of any that does the same for TeX input), so at least you
> know when your source should compile. And one tip (something I have
> started too late): put your lua code in a separate file and call it from
> within your TeX environment, that way, context's error messages become
> more precise.

in most cases the filtering is is straightforward: \xmlflush, xmlfirst, 
xmlall + a simple path into the tree (relative to the current node)

it becomes more complex if data has to come from other places (combining 
xml nodes) but once you need that, you probably know what you're dealing 
with anyway

concerning tracing: there are some trackers  (lxml.*) that show the 
results of filtering, and if you want to see what goes in deep down you 
can try

\enabletrackers[context*]

but this also shows data generated and passes by other mechamisms.

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________