RE: [xsl] XLST Processors that support JavaScript

["Kirk Allen Evans" <kaevans at xmlandasp dot net>]

> -----Original Message-----
> From: owner-xsl-list@lists.mulberrytech.com [mailto:owner-xsl-
> list@lists.mulberrytech.com] On Behalf Of Eric Promislow
> Sent: Wednesday, September 04, 2002 1:25 PM
> To: xsl-list@lists.mulberrytech.com
> Subject: RE: [xsl] XLST Processors that support JavaScript
> 
> Kirk, the other issue here is how to access the MS XPath
> extensions derfined in MSXML 4.0.  
<snip>
> I can't figure out how to access this namespace without writing a
> .net wrapper class around MSXML 4.   Is there a way of doing this
> inside System.Xml.Xsl XSLT?

I was watching the related thread on visual-xslt-discuss regarding
support for the msxsl:format-date extension in .NET.  

The extension functions defined in urn:schemas-microsoft-com:xslt are
not supported in .NET, they are only supported in MSXML 4.0, as noted in
my post at Microsoft.public.dotnet.xml [1].  This was confirmed as well
by Chris Lovett and Dare Obasanjo, both of Microsoft.  

The workaround recommendation from most people on this mailing list
would be not to use extensions, favoring an XSLT solution.  A good
reference is the datetime_lib.xsl functions from Marrowsoft's Xselerator
(Dimitre:  does FXSL support a date library now?)  

That said, you can still use C# extensions, and you don't have to resort
to using extension objects with XsltArgumentList:  Since .NET's XSLT
parser supports C#, you can use some of the .NET framework classes
directly in conjunction with the msxsl:script element.  Agreed that the
msxsl:format-date function is easier to manage than the System.DateTime
approach, using inline extensions seems to help simplify the solution
somewhat (although I would prefer the ability to debug compiled objects
rather than rely on an external debugger, even though VisualXSLT rocks)
).  

If they don't want to inline the extension, they can use an XSLT include
or import to pull the vendor-specific stuff in (or hide it and make it
easier to work with).  I would have named the function "format-date" for
consistency, but C# balked at that name.  I posted the stylesheet to be
imported at my web site (URL in the stylesheet below) to show a working
demonstration:

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" 
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; 	
	xmlns:foo="urn:schemas-xmlandasp-net:xslt">

	<xsl:import href="http://www.xmlandasp.net/msxslext.xslt"/>
	
	<xsl:template match="/">
		<h1>user:FormatDate</h1>		
		<xsl:value-of
select="foo:formatdate('1996-08-01','MMMM')"/>		
	</xsl:template>
</xsl:stylesheet>

Here is what the combined stylesheet (including import) really looks
like, should they choose to use a local copy instead of pulling from a
remote server.

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" 
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; 
	xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
	xmlns:user="urn:schemas-xmlandasp-net:xslt">
	<msxsl:script language="C#" implements-prefix="user">
		string formatdate(string wholeDate,string format)
		{
			string yearPart = wholeDate.Substring(0,4);
			string monthPart = wholeDate.Substring(5,2);
			string dayPart = wholeDate.Substring(8,2);
			DateTime mydate = new
DateTime(int.Parse(yearPart),int.Parse(monthPart),int.Parse(dayPart));
			
			return(mydate.ToString(format));
		}
	</msxsl:script>
	<xsl:template match="/">
		<h1>user:formatDate</h1>
		<xsl:value-of
select="user:formatdate('1996-08-01','MMMM')" />
	</xsl:template>
</xsl:stylesheet>


[1]
http://groups.google.com/groups?q=evans+date+xslt&hl=en&lr=&ie=UTF-8&oe=
UTF-8&selm=eJLf8BJ7BHA.2464%40tkmsftngp05&rnum=2

Kirk Allen Evans
http://www.xmlandasp.net
Author, "XML And ASP.NET", New Riders Publishing
http://www.amazon.com/exec/obidos/ASIN/073571200X



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list