On Jun 4, 2009, at 7:16 PM, Dimitre Novatchev wrote:

> On Thu, Jun 4, 2009 at 4:10 PM, Robert Koberg <rob@k...> wrote:
>> And of course once you compile it with a specific processor you  
>> lose one of
>> the best things about an XSL stylesheet: the ability to run it on  
>> more than
>> one processor.
>
> JVM byte-code or .NET IL code both are not processor-specific.
> Fortunately, there is no need for XSLT byte-code :)
>

Are you saying that you would not need, for example, java Saxon to run  
XSLT compiled by java Saxon?

But, still, you can't run XSL compiled in java in another language  
while you can run uncompiled XSL file(s).

-Rob

>
>
> -- 
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant  
> intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> You've achieved success in your field when you don't know whether what
> you're doing is work or play
>
>
>
>
>>
>> -Rob
>>
>>
>> On Jun 4, 2009, at 6:52 PM, Dimitre Novatchev wrote:
>>
>>> Many XSLT processors can compile a (at least a main/primary)
>>> stylesheet to executable code. AFAIK Saxon can compile to Java
>>> byte-code or Java source code and .NET XslCompiledTransform compiles
>>> to .NET IL code. Many years ago Sun provided such "XSLT compilation.
>>>
>>> In this way a single application written in XSLT can be offered in
>>> executable code and this is usually a significant part of the
>>> technical protection of any software application.
>>>
>>> What is still missing is the ability to compile a set/library of
>>> stylesheets that can be used by a primary stylesheet at runtime.
>>> Though there is not any provision in the W3 Spec how to do this for
>>> XSLT (I think things are better for XQuery), a de-facto
>>> standard/implementation would be extremely useful. Not only some
>>> existing libraries such as FXSL, FunctX, ()one put here any EXSLT
>>> *implementation*, although EXSLT is just a specification, and by
>>> default the implementations are not in XSLT themselves) etc., would
>>> benefit from easier deployment (say in browsers), but this will
>>> stimulate authors to write more such libraries -- to the benefit of
>>> the whole XSLT developers community.
>>>
>>> I would welcome if EXSLT2 specifies a mechanism for run-time binding
>>> between a main stylesheets and one or more compiled libraries of
>>> functions/templates.
>>>
>>>
>>> --
>>> Cheers,
>>> Dimitre Novatchev
>>> ---------------------------------------
>>> Truly great madness cannot be achieved without significant  
>>> intelligence.
>>> ---------------------------------------
>>> To invent, you need a good imagination and a pile of junk
>>> -------------------------------------
>>> Never fight an inanimate object
>>> -------------------------------------
>>> You've achieved success in your field when you don't know whether  
>>> what
>>> you're doing is work or play
>>>
>>>
>>>
>>> On Thu, Jun 4, 2009 at 1:21 PM, Paul Kiel <paul@x...>  
>>> wrote:
>>>>
>>>> Hi Folks,
>>>>
>>>> Had an interesting discussion that I started on a Linkedin group,  
>>>> but
>>>> should
>>>> probably have started here.  I had originally asked the question  
>>>> "can you
>>>> sell an XSLT?".  And by that I don't mean is it possible, but would
>>>> anyone
>>>> buy one.  What is the market for XSLTs as products?
>>>>
>>>> The comments clearly indicated that people are willing to (and  
>>>> actually
>>>> do)
>>>> buy XSLTs.  They tend to come in two forms.  First, a specific  
>>>> solution
>>>> to a
>>>> specific task.  A key niche need.  Second, there is the idea of  
>>>> XSLT as a
>>>> software platform.  XSLT as programming in Xml.  I've certainly  
>>>> thought
>>>> this
>>>> because I've been working with xml for so long that I *think* in  
>>>> terms of
>>>> Xml (perhaps there is a 12 step program for this).  So XSLT to me  
>>>> is the
>>>> java of Xml.  Of course no offense to java users, myself being  
>>>> one too.
>>>>
>>>> The reason I brought this up is that while I've been involved in  
>>>> open
>>>> source
>>>> XSLT work as well as created innumerable ones for clients  
>>>> individually, I
>>>> have lots of ideas about XSLTs as general products.
>>>>
>>>>  Ken Holman of course highlighted a key component to this topic,  
>>>> which is
>>>> obfuscation in order to protect intellectual property.   That  
>>>> would be
>>>> the
>>>> difference between open source and product solutions.
>>>>
>>>> So I post these comments here wondering if you have thoughts on  
>>>> this
>>>> topic
>>>> as well.  Would love to hear them.
>>>>
>>>> Cheers,
>>>>
>>>> Paul Kiel
>>>>

--~------------------------------------------------------------------
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@l...>
--~--