Re: [xsl] saxon:evaluate() in schematron

Hi,

Rick's advice is always excellent, but any good advice can be applied 
badly. And I don't find that the requirement for portability always 
trumps everything. (In fact sometimes it doesn't trump anything.) In 
Schematron (we are OT), maintainability and extensibility are often more 
important: it depends on the use case, I think.
Then too, Rick's post is in reaction to an extreme example, and 
explicitly allows for three exceptions, including "... where it is more 
convenient to express some very convoluted XPath access as a function 
because of information hiding (rather than abstraction) reasons." I 
think Matt has one of these.
As for "wean[ing] ourselves of the for-loop mentality", I dare say Matt 
has done that long ago. :-) In fact, we have to do more XQuery-like 
for-looping here to do without the stylesheet function than we would 
using it.
Nevertheless I'm grateful for the link, and seeing a solution without a 
function shows we have choices.
Cheers,
Wendell

On 5/21/2012 5:37 PM, Imsieke, Gerrit, le-tex wrote:
> Wendell, Matt,
>
> I recently came across this blog post by Rick Jelliffe, “Do you need to
> make your own XSLT2 function definitions when using Schematron?”
> http://broadcast.oreilly.com/2010/09/do-you-need-to-make-your-own-x.html
>
> Although it is tempting for XSLT2 pundits to introduce user-defined
> functions in their Schematrons, Rick’s post has made me resist this
> temptation every time since I read it. If only for the reason that
> without user-defined XSLT functions, Schematron schemas are more
> portable, as we’ve seen today.
>
> Rick also proposes ‘let’ as a tool to break up iterations or, as in
> Matt’s example, complex expressions.
>
> I’ve reworked my solution using let:
>
> <s:rule context="line">
> <s:let name="outliers" value="
> for $att in
> (@x1, @x2)[
> xs:integer(.) gt
> xs:integer(../../../block[@n eq current()/@n]/@x2)
> or
> xs:integer(.) lt
> xs:integer(../../../block[@n eq current()/@n]/@x1)
> ]
> union
> (@y1, @y2)[
> xs:integer(.) gt
> xs:integer(../../../block[@n eq current()/@n]/@y2)
> or
> xs:integer(.) lt
> xs:integer(../../../block[@n eq current()/@n]/@y1)
> ]
> return concat(name($att), '=', $att)
> "/>
> <s:report test="exists($outliers)">
> Line <s:value-of select="@n"/> does not fit.
> Offending coordinate(s): <s:value-of select="$outliers" />
> </s:report>
> </s:rule>
>
> –Gerrit
>
> On 2012-05-21 23:17, Wendell Piez wrote:
> > Matt,
> >
> > Of course, I forgot that you'll probably want, or need, the function
> > also to say as="xs:boolean". (And who knows what else.)
--
======================================================================
Wendell Piez                            
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--