Dear Massimo, 1. A solution that is specific to xml may not be a good idea. That is not a generic solution. 2. Re-compiling code is not an out-of-the-box solution. Doing this where run-time work-around doesn't exist is fine.
This, if we don't want to touch the documentation and test-suites, leaves us with the only option of writing a proc that Jeff suggested. If we are OK with touching the documentation and test suites, another middle-ground solution, in the same lines of what Jeff suggested, is to introduce a run-time switch that tells Rivet the tags to exclude: RivetServerConf ExcludeStartTags "return [list <?xml <?tag2]" This solution may save writing new procs and will be open for future contentions with other <? tags. All said, I understand that we have a work-around for now and this may not be a high-priority change. Best Regards, Nagu. On Thu, Jul 26, 2012 at 11:33 PM, Massimo Manghi <[email protected]>wrote: > On 2012-07-26 15:38, Nagarajan Chinnasamy wrote: > >> So, we need to find a solution that will: >> >> 1. maintain backward compatibility (not breaking the ones without >> space after <?) >> 2. co-exist with other "<?" usages (like <?xml) >> > > let's look at it in a different way for a minute. We don't have to > necessarily support the <?xml ...?> tag everywhere. We have to detect the > standard header for a canonical XML document which occurs at the very > beginning of it. Would it make the problem easier to tackle with the > current code of Rivet? Just wondering... > > > 3. not need users to recompile Rivet or write code >> > > I'm against the adoption of a run time switch basically on the ground that > Rivet has to declare and support one way to embed scripts. This has also > would impact the documentation and the test suite. Anyone wanting to use > different start/end tags can do it rebuilding and redefining > START_TAG/END_TAG. I never tested the effect of defining START_TAG as > "<?rvt", definitely it would be a good test to see if those preprocessor > symbols are used consistently in the parser throughout. A sign the code is > well written from this point of view. In case a switch for the 'configure' > script could make things easier (--with-start-tag=..., --with-end-tag=...). > > -- Massimo > >
