This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Regular expression functions (Was: Re: comments on December F&O draft)
Hi David,
>> Honestly, I can't see much difference between having to handle this
>> syntax and having to handle:
>
> ah that's easy I just use d-o-e for that:-)
Quite. But (I think) you would recommend to people who presented you
with that kind of format, that changing the source XML was a better
way than trying to design a stylesheet to do it. Did I get it right,
by the way? ;)
> I'm not convinced yet actually, I think it duplicates too much
> existing xslt functionality. It's clear that lex/yacc accepts a
> larger class of grammars than regular expressions (I see Dimitre's
> already supplied the details), but I think (somehow) the extra
> functionality (which basically just always comes down to nesting,
> counting and storing information for look-ahead) is already present
> in xslt so the trick is to add regexp support (only) in a way that
> the extra arithmetic functionality can be pulled from xpath/xslt for
> those occasions when you need it. Since we argued a long time ago
> that xslt was turing complete (given an approximation to an infinite
> tape) everything's possible anyway so it's only a matter of
> convenience.
Well of course it's all just a matter of convenience :) This seemed a
very convenient way, to me, of parsing what you'd described. I'd
rather describe the grammar than describe the parsing process, if you
see what I mean. Perhaps it's all the BNF in the WDs affecting me...
The really light-weight method is a simple match() function that
returns start/length pairs of integers. If you have that, then
assuming that templates were allowed to match simple typed values, you
can parse your string with something like:
<xsl:template match="value of type xs:string" mode="row">
<xsl:variable name="match" select="match(., '^\\([a-z]+)\{')" />
<xsl:choose>
<xsl:when test="$match[1] = 1">
<xsl:variable name="name"
select="substring(., $match[3], $match[4])" />
<start name="{$name}" />
<xsl:apply-templates select="substring(., $match[2])"
mode="row" />
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="." mode="expr" />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
... and so on in a way that it's really too late at night to detail.
You can manually keep track of brackets with parameters and so on.
I imagine that this is similar to what you're doing at the moment,
just that the regexp rather than substring() et al. might make some of
your life easier.
Actually, I think that the \frac{...}{...} construct is fairly
difficult to handle, but like you say, anything can be done.
I'll think some more...
> given a lex implementation you could (I think, haven't checked)
> implement an Xpath parser if you wished...
Already got an XPath parser. Parsing is the easy part of evaluate() -
the evaluation is the hard part (to implement in XSLT).
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list