XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Peter JaffeSubject: format-number in 3.1.59a
Author: Peter Jaffe
Date: 07 Sep 2001 02:29 PM
It seems that the XSLT function format-number requires a 1.2.2 or above JRE?

Since this isn't an extension functions, I would hope there would be no dependencies on an external JRE.

I am including an example XSL, XML, and screen shot of the error message.

NOTE: There is more in the XML than necessary to create this problem, but I wanted to confirm that function-available() returned true for this. As a result, I was a bit curious that the node testing functions (e.g. current(), node(), ...) claimed to not be available?

One additional point: a nice addition would be to be able to create a scenario for an XML that isn't saved to disk. The option to identify a Project File almost seems to work, but when you open the file filter, you see an icon (no file name) that represents the unsaved XML but selecting it doesn't work. This would be a nice feature to allow for non-invasive proof-of-concept or testing. Although the work around is trivial :)


Applicationformat-number.xml
test XML

Documentformat-number.xsl
test XSL

DocumenterrorMsg.jpg
Error message

Postnext
Minollo I.Subject: Re: format-number in 3.1.59a
Author: Minollo I.
Date: 07 Sep 2001 02:56 PM

>It seems that the XSLT function format-number requires a 1.2.2 or above JRE?

That's correct.

>Since this isn't an extension functions, I would hope there would be no
>dependencies on an external JRE.

Yes, format-number does depend an external JRE; the behavior of
format-number is equivalent to what you have in Java; we have chosen this
shortcut for the time being (the assumption being that in most cases users
have at least a 1.2.x JRE installed on their machines).

>I am including an example XSL, XML, and screen shot of the error message.
>
>NOTE: There is more in the XML than necessary to create this problem, but
>I wanted to confirm that function-available() returned true for this. As
>a result, I was a bit curious that the node testing functions (e.g.
>current(), node(), ...) claimed to not be available?

current() and node() do not appear as available functions because they are
not really implemented as functions, but as pieces of the XPath processor.
I think they should be returned as available, even if I'm puzzled about why
MSXML and Xalan-J are returning current() as available and node() as not
available.
Basically the only difference between what Stylus Studio reports as
available and what MSXML and Xalan-J do, is the current() function, that we
return as not available.
We'll investigate further.

>One additional point: a nice addition would be to be able to create a
>scenario for an XML that isn't saved to disk. The option to identify a
>Project File almost seems to work, but when you open the file filter, you
>see an icon (no file name) that represents the unsaved XML but selecting
>it doesn't work. This would be a nice feature to allow for non-invasive
>proof-of-concept or testing. Although the work around is trivial :)

I see what you are saying; we will remove the untitled icons from the
project area in the Open File dialog, as you are currently not supposed to
be able to use an untitled file for anything.
Changing this in the direction you would like to see is tricky, and I don't
think it will happen anytime soon.

Thanks,
Minollo

Postnext
Peter JaffeSubject: Re: format-number in 3.1.59a
Author: Peter Jaffe
Date: 07 Sep 2001 05:24 PM
On 9/7/01 2:56:40 PM, Carlo Innocenti wrote:

> Yes, format-number does depend an external JRE; the behavior of
> format-number is equivalent to what you have in Java; we
> have chosen this shortcut for the time being (the assumption
> being that in most cases users have at least a 1.2.x JRE
> installed on their machines).

I understand how implementing it this way could definitely save time (particularly when the XSLT spec defines the function as behaving like JDK1.1 DecimalFormat class). However, one of my goals is to isolate presentation layer development from application layer development, therefore installing a JRE would be an additional requirement for a "UI designer" machine.

Given 4 machines in our office, all of which have 1+ JDK/JRE installed on them (at least one of which is 1.2.2 or higher), only on 2 of them were configured such that Stylus Studio was able to automatically identified a compatible JRE (one picked up an Oracle 1.1.7, and I'm not sure what the other found).

It seems that the necessary requirements are:
1. Having a JRE bin directory in your system PATH
2. Having "Tools>Options>Application Settings>Java Virtual Machine" properly configured (which it attempts to auto-detect)

Requirement 1 is what disturbs me the most, followed closely by item 2.

I don't know what your timeline is for internalizing format-number(), but I personally cringe when a shrink wrapped product has a core function that requires "proper" installation of another toolkit. Has that been a common design pattern, and I have just uncovered the first of a few/many?

Thanks.

Pete

Postnext
Ivan PedruzziSubject: RE: format-number in 3.1.59a
Author: Ivan Pedruzzi
Date: 07 Sep 2001 05:50 PM
Hi Peter,

having the JRE bin in the PATH is *not* a requirement, Studio use the
registry to perform the JVM auto detect. Take a look under

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime
Environment\CurrentVersion

Stylus Studio requires a compatible 1.2 JVM.

Hope this help


Ivan Pedruzzi
eXcelon Corporation
http://www.stylusstudio.com



> -----Original Message-----
> From: stylus-studio-tech Listmanager [mailto:listmanager]
> Sent: Friday, September 07, 2001 5:31 PM
> To: Recipients of 'stylus-studio-tech' suppressed
> Subject: Re: format-number in 3.1.59a
>
>
> From: "Peter Jaffe"
>
> On 9/7/01 2:56:40 PM, Carlo Innocenti wrote:
>
> > Yes, format-number does depend an external JRE; the behavior of
> > format-number is equivalent to what you have in Java; we
> have chosen
> > this shortcut for the time being (the assumption being that in most
> > cases users have at least a 1.2.x JRE installed on their machines).
>
> I understand how implementing it this way could definitely
> save time (particularly when the XSLT spec defines the
> function as behaving like JDK1.1 DecimalFormat class).
> However, one of my goals is to isolate presentation layer
> development from application layer development, therefore
> installing a JRE would be an additional requirement for a "UI
> designer" machine.
>
> Given 4 machines in our office, all of which have 1+ JDK/JRE
> installed on them (at least one of which is 1.2.2 or higher),
> only on 2 of them were configured such that Stylus Studio was
> able to automatically identified a compatible JRE (one picked
> up an Oracle 1.1.7, and I'm not sure what the other found).
>
> It seems that the necessary requirements are:
> 1. Having a JRE bin directory in your system PATH
> 2. Having "Tools>Options>Application Settings>Java
> Virtual Machine" properly configured (which it attempts to
> auto-detect)
>
> Requirement 1 is what disturbs me the most, followed closely
> by item 2.
>
> I don't know what your timeline is for internalizing
> format-number(), but I personally cringe when a shrink
> wrapped product has a core function that requires "proper"
> installation of another toolkit. Has that been a common
> design pattern, and I have just uncovered the first of a few/many?
>
> Thanks.
>
> Pete
>
>
>
> To reply: mailto:stylus-studio-tech.3633@edn.exceloncorp.com
> To start a new topic: mailto:stylus-studio-tech@edn.exceloncorp.com
> To login: http://edn.exceloncorp.com/~SSDN
>
>

Postnext
Peter JaffeSubject: RE: format-number in 3.1.59a
Author: Peter Jaffe
Date: 07 Sep 2001 06:05 PM
Got it.

It would still be nice to see that external dependency severed for core XSLT functionality, but since it isn't a show stopper, I'll quit complaining...

Pete

Postnext
Minollo I.Subject: Re: format-number in 3.1.59a
Author: Minollo I.
Date: 07 Sep 2001 05:55 PM

>...
>I don't know what your timeline is for internalizing format-number(), but
>I personally cringe when a shrink wrapped product has a core function that
>requires "proper" installation of another toolkit. Has that been a common
>design pattern, and I have just uncovered the first of a few/many?

I'm leaving to Ivan the discussion about the Java requirement issues.

About requiring "proper" installation other toolkits: Stylus Studio
requires that a JRE is properly installed on the machine where it is
running only for three particular functionality:
- format-number
- user-defined Java extension functions
- advanced Java editing, compiling and execution
If you want to debug Java extension functions (or Java applications in
general), the requirement is extended to JDK.

Stylus Studio, as any other application, relies on a "proper" installation
of several components; as we are using Microsoft technology for all the
non-internal functionality other than the ones mentioned above, in most
cases such "proper" installation is equivalent to a "Windows NT/2000/XP
proper installation".

As Java is not part of the extended concept of OS that Microsoft has (only
for the reasons we all know about), the Java requirement suddenly becomes
annoying.
We understand that; we'll do our best to improve the auto-detection
mechanism of a JVM installation; but, I will be frank with you, we don't
have plans at this point to port the format-number implementation to the
native application C++ world anytime soon.

Hope this helps,
Minollo

Posttop
Peter JaffeSubject: Re: format-number in 3.1.59a
Author: Peter Jaffe
Date: 07 Sep 2001 06:07 PM
Minollo,

Thanks for your detailed reply, and I definitely see your points.

Pete

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.