Re: the joy of breaking out from procedural/imperative programming style

Gunther,

Cool! Yes, realizing that the specs are well on their way to becoming solid,
getting a voice to raise the modularity issue of data types I think is still
crucial. I find it significant that the one area that is still very much in
flux with the XPath WD comes in this very area -- there's a lot of unease
with data types by those that seem to be promulgating the standards, and it
shows in the ambiguities still in the document in that regard (not to
mention the explosion of constructors and the need for unfortunate functions
like get-minutes-from-dateTime($dt), which is actually longer than
"substring($dt,13,2)" that does exactly the same thing without carrying
around a date object).

I really like the lambda functionality. The biggest argument against such
constructors though seems to be the same thing that is keeping eval() out of
the XPath lexicon, as useful as it can be: it might necessitate the
capability to support run-time evaluation, which can be expensive in
compiled versions of XSLT. This is one of the reasons that I see it as an
extension class, rather than an intrinsic one -- as an XPath/XSLT or
XPath/XQuery vendor you can support it for non-compiled processors and drop
it for compiled ones. This isn't as imperative (pardon the pun) with
extension functionality; this is presumably already pre-compiled, so
integrating it would not break the compilation dependent XPath parsers.

--Kurt

----- Original Message -----
From: "Gunther Schadow" <gunther(_at_)aurora(_dot_)regenstrief(_dot_)org>
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Cc: "Paul Biron" <Paul(_dot_)V(_dot_)Biron(_at_)KP(_dot_)ORG>
Sent: Friday, December 06, 2002 1:09 PM
Subject: Re: the joy of breaking out from procedural/imperative programming
style (was: Re: [xsl] Peculiar Problem in .xsl file


> Kurt and David,
>
> Absolutely, it is not right to elevate the XML Schema data types
> into a special privilledged status in XPath. If this is what's
> being done, it needs to be stopped. I am cc-ing the editor of the
> Schema spec to this email, and he just happens to be that same
> friend who has a vote and could help.
>
> XPath should be modular and impartial as to what schema language
> and certainly what data types are used. That's one of those things
> the RELAX NG has fairly right. I think its crucial the XSLT and
> XPath remain unencumbered from such things.
>
> Whether functions should be opaque objects of the same nature as,
> say, timestamps, however, I beg to differ. At least in XSLT, I
> would much rather see an XML form that defines a lambda form.
> Because I really do think that the whole point of functions as
> data in XSLT is lost if a function is just a string in some
> obscure non-XML syntax.
>
> Because we now say in XSLT:
>
> <xsl:function name="dt:monthName"
>                xmlns:dt="http://www.mySchemas.com/date";>
>    <xsl:param name="date"/>
>    <xsl:param name="lang"/>
>    <xsl:return select="$locale/
>              month[    @digits=substring($date, 5, 2)
>                    and @xml:lang=$lang][1]/@name"/>
> </xsl:function>
>
> we could just as well say:
>
> <xsl:variable name="dt:monthName"
>                xmlns:dt="http://www.mySchemas.com/date";>
>    <xsl:lambda>
>      <xsl:param name="date"/>
>      <xsl:param name="lang"/>
>      <xsl:return select="$locale/
>              month[    @digits=substring($date, 5, 2)
>                    and @xml:lang=$lang][1]/@name"/>
>    </xsl:lambda>
> </xsl:variable>
>
> instead of some obscure "let" form in XSLT.
>
> I'd even like to undo more of the XPath special syntax. Just remember
> LISP: the power of functions as data was so obvious in the symbolic
> differentiation example, where an S-EXPR was easily analyzed with
> the normal CAR and CDR functions, the derivative CONSed together
> and then executed just as easily with EVAL. In XPath you can't
> analyze anything unless you're willing to write your own parser with
> lots of work.
>
> regards,
> -Gunther
>
>
>
> Kurt Cagle wrote:
>
> > David,
> >
> > I'm in 100 % agreement with you wrt to building functions as distinct
> > objects, and to the polluted aspect of XPath as a tool for the database
> > vendors.  To the latter point first, it seems to make a great deal more
> > sense to create modular type support rather than trying to impose PSVI
(Post
> > Schema Validated Instance) into the grove/sequence model. Dates (and
date
> > functions) would then fall into their own distinct namespace:
> >
> > xpathTypeDef xmlns:date = "http://www.w3.org/XMLSchemaInstance/Date";
> >
> > Xpath would then support a generic object type (I believe it already
does,
> > for that matter) that could then work with the external constructors:
> >
> > date:getMonth(date:new('2002-12-05'))
> >
> > The same model could be used to add support for other extension
functions in
> > a cohesive manner, and is not radically different from the way things
are
> > done now, save that it gets the entire ugly data type model out of XPath
and
> > into a user supported set of functionality where it belongs. You can use
> > Xpath 2 without PSVI perfectly well, and if you want the overhead of
PSVI
> > you can add it yourself.
> >
> > I think this feeds into the former point as well. If you treat a
function as
> > a distinct object in its own right (a concept that is intrinsic to
> > declarative programming btw), then an external API should be able to be
> > written that supports functional manipulation. This would also go a long
way
> > to making XPath a fully functional language in its own right -- there is
> > absolutely no reason why you could not do:
> >
> > xpathTypeDef xmlns:fn = http://www.w3.org/Xpath2/Function
> >
> > <xsl:variable name="seqence" select="let
> > $f:=fn:define($a,$b,$c,'union(intersect($a,$b),$c'),
> > fn:evaluate($f,(1,2,3),(2,3,4),(5))"/>
> >
> > Of course this breaks the barrier of the no-post-evaluation mindset,
which
> > I've always felt to be a silly restriction anyway.
> >
> > I know, I know,  I'm preaching to the choir here.
> >
> > -- Kurt
> >
> > ----- Original Message -----
> > From: "David Carlisle" <davidc(_at_)nag(_dot_)co(_dot_)uk>
> > To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
> > Sent: Friday, December 06, 2002 11:44 AM
> > Subject: Re: the joy of breaking out from procedural/imperative
programming
> > style (was: Re: [xsl] Peculiar Problem in .xsl file
> >
> >
> >
> > > > #1 the function is data, but I'd have to do code generation to handle
> > > >    it as data and then execute the generated style sheet to execute
> > > >    the function.
> > > It's not clear how you'd map some standard FP constructs like "map"
> > > in that model. It may be possible (Dimitre's shown anything's possible
> > > in this area if you really set your mind to it:-) but It seems to me
> > > that functions as first class objects that could be passed as arguments
> > > to other functions could have been added to the model. and would have
> > > been a whole lot cleaner and more useful than 1001 functions for
> > > handling gxmlQueryDateTypes.
> > >
> > >
> > >
> > > > #2 what do you mean when you say "shame about the rest of xpath2
> > > >    though"?
> > > if I had a vote I wouldn't let xpath2 drafts pass on to
> > > w3c recommendation status. I think it's been hijacked into a database
> > > query language for typed data at the expense of its original use for
> > > querying documents at greatly at the expense of loss of cross platform
> > > portability. See other threads on this list and xml-dev in the last
> > > couple of days.
> > >
> > >
> > > > Aren't you one of the guys "in control" of that spec?
> > > No. I'm just a user, I'm not on the working group.
> > >
> > > David
> > >
> > > _____________________________________________________________________
> > > This message has been checked for all known viruses by Star Internet
> > > delivered through the MessageLabs Virus Scanning Service. For further
> > > information visit http://www.star.net.uk/stats.asp or alternatively call
> > > Star Internet for details on the Virus Scanning Service.
> > >
> > > XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
> --
> Gunther Schadow, M.D., Ph.D.                    
> gschadow(_at_)regenstrief(_dot_)org
> Medical Information Scientist      Regenstrief Institute for Health Care
> Adjunct Assistant Professor        Indiana University School of Medicine
> tel:1(317)630-7960                         http://aurora.regenstrief.org
>
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

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