Amit Kumar Pandey | 1 Oct 11:27 2003

Exponential Number In XSLT?

Dear Sir/Madam,
I'm stuck up in dealing with presenting an exponential number ,coming from XML, in XSLT.
It's giving the output as NaN.
 
Please let me know at the earliest , how this problem can be dealt with.
It's very urgent.
 
Regards,
Amit
 
Kay, Michael | 1 Oct 14:28 2003

RE: Exponential Number In XSLT?

Requests for coding help with XSLT are best addressed to the xsl-list at www.mulberrytech.com

XSLT 1.0 does not provide any support for reading or writing numbers using exponential notation. You will need to use an extension function for this purpose.

regards,

Michael Kay

> -----Original Message-----
> From: Amit Kumar Pandey [mailto:Amit_P <at> infosys.com]
> Sent: 01 October 2003 10:42
> To: xsl-editors <at> w3.org
> Subject: Exponential Number In XSLT?
>
>
> Dear Sir/Madam,
> I'm stuck up in dealing with presenting an exponential number
> ,coming from XML, in XSLT. It's giving the output as NaN.

> Please let me know at the earliest , how this problem can be
> dealt with. It's very urgent.

> Regards,
> Amit

>

David.Pawson | 2 Oct 09:25 2003
Picon

RE: [xsl] XSL:FO - How to wrap non-word strings in table cells?


Eliot wrote:
> Different FO implementations behave differently, but in 
> general, unless 
> you provide break points using either zero-width spaces or 
> soft hyphens, 
> the renderer will not break the text for you because it really isn't 
> licensed to do so, except possibly as an overflow fallback.
> 
> It would probably be useful for XSL FO implementations to 
> provide some 
> way to configure their behavior in these sorts of situations, but 
> anything like that would be outside the scope of what the FO 
> spec defines.

Since it is requested so often, perhaps asking the WG to consider
a solution is appropriate?

The most often requested place is a table cell,
so perhaps something like a hint to the processor,
break-at="20" meaning if needed, presume a soft-hyphen at character position
20 within any word?

Any other suggestions anyone?

regards DaveP

- 

NOTICE: The information contained in this email and any attachments is 
confidential and may be legally privileged. If you are not the 
intended recipient you are hereby notified that you must not use, 
disclose, distribute, copy, print or rely on this email's content. If 
you are not the intended recipient, please notify the sender 
immediately and then delete the email and any attachments from your 
system.

RNIB has made strenuous efforts to ensure that emails and any 
attachments generated by its staff are free from viruses. However, it 
cannot accept any responsibility for any viruses which are 
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk 

Kay, Michael | 2 Oct 12:00 2003

RE: un-parsed....function limitation...

The XSLT unparsed-text() function returns a string, so it is clearly not suitable for this purpose; similarly the <xsl:result-document> instruction produces a document represented in the data model, and optionally serializes it, so this doesn't naturally meet your requirement either.
 
If we wanted to provide something like this it would have to be done within the XPath data model and type system. The appropriate types for representing binary data are xs:binHex and xs:base64. This would suggest a function such as unparsed-binary() which loads a binary file and returns an xs:binHex value, and perhaps an instruction <xsl:output-binary-file> which writes an xs:binHex value as a binary file.
 
I think the right thing to do with requirements such as this is to pioneer them as user-written extension functions (or instructions). If they prove useful and popular they will start to become standardized within libraries such as EXSLT (www.exslt.org). Only if there is real evidence that the requirement is a general one should we consider adding the functions to the core library. At present there are very many functions that some people might like and that we have chosen not to provide (for example, trigonometry functions), and I don't think we should add a function just because one user has a need for it. I would question whether there is really any value in XSLT being able to read and write binary files when it provides no functions or operators to actually manipulate their content.
 
Michael Kay
-----Original Message-----
From: Rajasekhar Cherukuri [mailto:rcheruku <at> genesyslab.com]
Sent: 01 October 2003 19:31
To: public-qt-comments <at> w3.org
Cc: xsl-editors <at> w3.org
Subject: un-parsed....function limitation...

There is one particular usage quite useful while transforming files.
What if the file need not be transformed but be preserved and transported.
 
Use case:
A binary image file that needs to be transported to another location as one of the multiple
<xsl:result-document/> calls done within an XSLT.
The XSLT could be picking up different/necessary images and sending across to another
location based on the original XML transformations.
 
Currently I did not come across a suitable way to do this in XSLT.
One way to do this is doing the following:
 <xsl:result-document format="binary-output"XXXX/myimage.gif"><xsl:value-of select="unparsed-text('ZZZ/myimage.gif','binary')"/></xsl:result-document>
But note that the encoding type I specificed is "binary" which is not part of the spec.
Is there any other way to do this in XSLT
or
can the committee consider:
 
a) either a new function "unparsed-binary(...)"
or
b) give "binary" option for the "unparsed-text(...)" function
or
c) give "binary" option and re-name "unparsed-text(...)" function to "unparsed-document(...)"
 
Thank You
 
Raja

 

Thank you

Raja

 
G. Ken Holman | 2 Oct 18:27 2003

RE: [xsl] XSL:FO - How to wrap non-word strings in table cells?


At 2003-10-02 08:25 +0100, David.Pawson <at> rnib.org.uk wrote:
>Eliot wrote:
> > It would probably be useful for XSL FO implementations to
> > provide some
> > way to configure their behavior in these sorts of situations, but
> > anything like that would be outside the scope of what the FO
> > spec defines.
>
>Since it is requested so often, perhaps asking the WG to consider
>a solution is appropriate?

I wouldn't subscribe to adding any such features in this area.

>The most often requested place is a table cell,
>so perhaps something like a hint to the processor,
>break-at="20" meaning if needed, presume a soft-hyphen at character position
>20 within any word?
>
>Any other suggestions anyone?

Yes, I suggest we should not go there.

Consider my example of wanting to break URLs at arbitrary locations (after 
each slash in my string).  If "the way to do this" is with a break-at= 
property, then I'll have to *still* use a zero-width space and not be able 
to take advantage of the property.

It is my opinion that the insertion of the character is the most flexible 
and the "correct" way to address this need, and indeed I teach the use of 
this character in my lecture on "breaks and keeps".

In general I would be worried that throwing in a lot of special use 
properties would bog down an already large specification, and the evidence 
is that the working group does put a lot of thought into adding any new 
properties.  I would hope that new properties would be general purpose in 
adding a feature usable in many situations rather than just special casing 
one particular situation (such as periodic breaking) out of a general case 
(breaking of lines).

I hope this helps.

.................. Ken

--
Next public US delivery:        3-day XSLT/2-day XSL-FO 2003-10-13
Next public European delivery:  3-day XSLT/2-day XSL-FO 2003-11-??
Instructor-led on-site corporate, government & user group training
for XSLT and XSL-FO world-wide:  please contact us for the details

G. Ken Holman                 mailto:gkholman <at> CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6                       Definitive XSLT and XPath
ISBN 0-13-140374-5                               Definitive XSL-FO
ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:     http://XMLGuild.info
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/s/bc

David.Pawson | 3 Oct 09:13 2003
Picon

RE: [xsl] XSL:FO - How to wrap non-word strings in table cells?


Ken
> In general I would be worried that throwing in a lot

1 is not a lot.

 of special use 
> properties would bog down an already large specification, 

Despite its repeated end user request?

Not sensible Ken.

regards DaveP.

- 
DISCLAIMER: 

NOTICE: The information contained in this email and any attachments is 
confidential and may be privileged. If you are not the intended 
recipient you should not use, disclose, distribute or copy any of the 
content of it or of any attachment; you are requested to notify the 
sender immediately of your receipt of the email and then to delete it 
and any attachments from your system. 

RNIB endeavours to ensure that emails and any attachments generated by 
its staff are free from viruses or other contaminants. However, it 
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments. 

Please note that the statements and views expressed in this email and 
any attachments are those of the author and do not necessarily represent 
those of RNIB. 

RNIB Registered Charity Number: 226227 

Website: http://www.rnib.org.uk 

Alexander Simons | 6 Oct 11:34 2003
Picon

Re: Do you have a time share?

Yes I have a time share unit in Jerusalem, Israel that I wish
to sell.
Does your company also deal in international resales?
Regards,
Alexander Simons 
Rujith de Silva | 30 Oct 19:11 2003

Using current() within a pattern

The XSLT spec, section 12.4, says:

    It is an error to use the current function in a pattern.

I understand why the current() function is useful only within nested
expressions, and is hence usually not of use in a pattern.  However,
if the pattern has doubly-nested square brackets, then the current()
function could be used to refer to the element two levels out.

When would that be useful?  Quite often, actually.  For example,
consider an XML file that looks like:

   <existing>
     <employee name="Fred" title="CEO"/>
     <employee name="Jane" title="CFO"/>
     ...
   </existing>
   <layoff>
     <employee name="Fred"/>
     ...
   </layoff>

Then to match existing employees that have been laid off, the
following pattern could be used:

   <xsl:template

match="existing/employee[/company/layoff/employee[ <at> name=current()/ <at> name]]">
     ...
   </xsl:template>

This finds the existing employees such that there's a layoff employee
element with a matching name.  The idiom is fairly clear, and uses
current() in an intuitive way.  current() within the [[doubly-nested
brackets]] refers, not to the element at the singly-nested level
[/company/layoff/employees], which would be unnecessary, but rather to
the next level up existing/employee, so it does the test just as
desired.

This is entirely consistent with the typical usage of current() within
templates.  For example, the spec gives the following example:

   <xsl:apply-templates select="//glossary/item[ <at> name=current()/ <at> ref]"/>

In this construct as well, current() refers, not the immediately
enclosing element //glossary/item, but to the next enclosing level,
which is the element that matched the template.  In each case,
current() within a path predicate refers, not to the Path element to
which that predicate applies, but to the node at the next level.

Furthermore, the construct with current() within a pattern works fine
with Apache's Xalan processor.  Xalan appears to ignore the
restriction regarding where current() may be used, and does the "right
thing" with the above construct.

Given the above, I suggest that the restriction against using
current() within a pattern be removed from the spec, or relaxed to
permit the above usage.

I've attached the following files:

- employees.xml (input)
- employees.xsl
- layoff.xml    (output)

Thanks,
Rujith de Silva.
Attachment (current.zip): application/x-zip-compressed, 1192 bytes
Kay, Michael | 31 Oct 19:43 2003

RE: Using current() within a pattern

The XSLT 2.0 working draft has removed the restriction on using current() within a pattern. The current() function, when used within a pattern, is defined to return the node that is being tested against the pattern.

Regards,

Michael Kay


> -----Original Message-----
> From: Rujith de Silva [mailto:desilva <at> netbox.com]
> Sent: 30 October 2003 18:16
> To: xsl-editors <at> w3.org
> Subject: Using current() within a pattern
>
>
> The XSLT spec, section 12.4, says:
>
>     It is an error to use the current function in a pattern.
>
> I understand why the current() function is useful only within
> nested expressions, and is hence usually not of use in a
> pattern.  However, if the pattern has doubly-nested square
> brackets, then the current() function could be used to refer
> to the element two levels out.
>
> When would that be useful?  Quite often, actually.  For
> example, consider an XML file that looks like:
>
>    <existing>
>      <employee name="Fred" title="CEO"/>
>      <employee name="Jane" title="CFO"/>
>      ...
>    </existing>
>    <layoff>
>      <employee name="Fred"/>
>      ...
>    </layoff>
>
> Then to match existing employees that have been laid off, the
> following pattern could be used:
>
>    <xsl:template

> match="existing/employee[/company/layoff/employee[ <at> name=curren
> t()/ <at> name]]">
>      ...
>    </xsl:template>
>
> This finds the existing employees such that there's a layoff
> employee element with a matching name.  The idiom is fairly
> clear, and uses
> current() in an intuitive way.  current() within the
> [[doubly-nested brackets]] refers, not to the element at the
> singly-nested level [/company/layoff/employees], which would
> be unnecessary, but rather to the next level up
> existing/employee, so it does the test just as desired.
>
> This is entirely consistent with the typical usage of
> current() within templates.  For example, the spec gives the
> following example:
>
>    <xsl:apply-templates
> select="//glossary/item[ <at> name=current()/ <at> ref]"/>
>
> In this construct as well, current() refers, not the
> immediately enclosing element //glossary/item, but to the
> next enclosing level, which is the element that matched the
> template.  In each case,
> current() within a path predicate refers, not to the Path
> element to which that predicate applies, but to the node at
> the next level.
>
> Furthermore, the construct with current() within a pattern
> works fine with Apache's Xalan processor.  Xalan appears to
> ignore the restriction regarding where current() may be used,
> and does the "right thing" with the above construct.
>
> Given the above, I suggest that the restriction against using
> current() within a pattern be removed from the spec, or
> relaxed to permit the above usage.
>
> I've attached the following files:
>
> - employees.xml (input)
> - employees.xsl
> - layoff.xml    (output)
>
> Thanks,
> Rujith de Silva.
>

Rujith de Silva | 31 Oct 20:38 2003

Re: Using current() within a pattern


Kay, Michael wrote:
 > The XSLT 2.0 working draft has removed the restriction on using
 > current() within a pattern. The current() function, when used within
 > a pattern, is defined to return the node that is being tested
 > against the pattern.

Thanks, that's great!
- Rujith.

--

-- 
http://home.earthlink.net/~rujith/


Gmane