If you are able to deploy a self-contained "package" of some sort, say 
a java .jar file.
You can store the XSLT text encrypted as a resource in the .jar,
decrypt the xslt at startup in memory, run the xslt and delete it.
It wont stop people from debugging into the jar and trying to get the 
decrypted XSLT in-memory but it would stop all but the most determined 
hacker.
David A. Lee
dlee(_at_)calldei(_dot_)com
http://www.xmlsh.org
On 8/30/2010 8:51 AM, G. Ken Holman wrote:
At 2010-08-30 15:04 +0530, Praveen Chauhan wrote:
It should be Protect from viewing the source code, and avoid 
unauthorized
modification.
But it should be work(run)
Nothing is foolproof.
But I've employed three different approaches:
(1) - Use an XSLT processor that "compiles" the XSLT into machine code,
      and then distribute only the machine code.  The Gregor XSLT
      processor is the best example I've seen of this.  Reverse
      engineering the XSLT is very difficult, but some modifications
      can happen.  Using various techniques for self-detection might
      prevent the modifications.
(2) - Obfuscate the XSLT code.  I've used this in the distribution of my
      Open Office XML filter that is obliged to be in clear text.  
Because
      XSLT is, itself, XML, I run my XSLT through obfuscation stylesheets
      that rewrite the entire logic with obscure and confusing variable
      names.  Reverse engineering is somewhat difficult ... certainly it
      would be painful.  I'm not too worried about someone figuring out
      some of my techniques.  Are you worried someone will steal your
      approaches to solving problems?
(3) - Employ digital signatures in the actual transformation scenario.
      This doesn't prevent the XSLT from being used on *other* XSLT
      processors, but it doesn't prevent the XSLT from being modified
      and running on the processor checking the digital signature.  In my
      case I worked with the Ibex XSL-FO processor from Visual 
Programming
      Ltd. to digitally sign my UBL stylesheets for the United Nations
      Layout Key:
         http://www.CraneSoftwrights.com/resources/ublss#ubl2-ss
      The stylesheets are shipped with a digital signature manifest.  The
      commercial-grade XSL-FO engine's "signature edition" can be 
downloaded
      at no charge because it will *only* execute digitally signed
      stylesheets.  I can make any of my stylesheets publicly 
downloadable
      and useable with a commercial-grade XSL-FO engine without users 
having
      to buy a copy of the engine.  Yes, they can use the stylesheets 
with
      other engines, but they may not be able to afford to buy a 
commercial-
      grade quality one.  Free engines may not work as well.  If they 
change
      even a single byte of the stylesheets the commercial engine will 
not
      work.  Thus, the vendor is protected from someone taking the 
freely-
      downloadable "signature edition" and using it for their own 
purposes.
      I've also digitally signed the OASIS technical specification 
stylesheets
      I wrote for OASIS committees to use with DocBook, so that project
      editors can freely use the commercial-grade engine with them:
http://docs.oasis-open.org/templates/DocBook/spec-0.5/oasis-specification-0.5-wd03.html#d0e1049 
I haven't yet combined (2) and (3) because the stylesheets I've wanted 
to sign are for the protection of the XSL-FO vendor not for the 
protection of my algorithms, but if I wanted to do both, then I simply 
run my obfuscation stylesheet on my original code and digitally sign 
and distribute the obfuscated version.
Nothing is perfect.  All you can hope for is to make it difficult to 
break ... you can't make it impossible.
I hope this helps.
. . . . . . . . . . . . Ken
--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--