Re: [xsl] strong typed variable with restriction ?

[Matthieu Ricaud-Dussarget <matthieu.ricaud@xxxxxxxxx>]

Hi Andrew,

Lookink athttp://www.w3.org/TR/xslt20/#xsl-choose, it seems the
xsl:otherwise element is not compulsary :
  Content: (xsl:when+, xsl:otherwise?)

When I type the function so it returs element()* instead of element() I
don't get the error anymore.

I don't really want to return an error node that I'll have to test
afterwards, at best I'd like the xslt processor to raise this error for
me when the passed param has not the good value.
I'm not sure about how to make a schema aware tranformation, but I have
a look in this direction.

Thanks for your help,


Matthieu.


Le 02/02/2011 11:39, Andrew Welch a icrit :
> On 2 February 2011 10:16, Matthieu Ricaud-Dussarget
> <matthieu.ricaud@xxxxxxxxx>  wrote:
> > Hi all,
> >
> > I have a xsl:function which :
> > - must return a element()
> > - has a string param "foobar".
> >
> > I typed $foobar as xs:string but I'd like to restrict the possible values to
> > "foo" or "bar".
> > I know it's possible to define such a constrain in a xsd schema, but is
> > there a way to do that in xpath2 ?
> >
> > This typing is important because the returned element() is selected from a
> > xsl:choose on $foobar value (with no otherwise) :
> >
> > My code looks like :
> > <xsl:function name="igs:get-css-rule" as="element()">
> > <xsl:param name="foobar" as="xs:string"/>  <!--(foo|bar)-->
> > <xsl:choose>
> > <xsl:when test="$foobar='foo'">
> > <xsl:sequence select="igs:get-my-foo-item()"/>
> > </xsl:when>
> > <xsl:when test="$css='bar'">
> > <xsl:sequence select="igs:get-my-bar-item()"/>
> > </xsl:when>
> > </xsl:choose>
> > </xsl:function>
> >
> > And I get such a parsing  error on my xslt :
> >   XTTE0570: Conditional expression: If none of the conditions is satisfied,
> > an empty
> You get the error because you must have an xsl:otherwise, you can't
> just have xsl:whens.
>
> Regarding the 'foo' 'bar' part, it depends what you want to happen -
> you could add an otherwise and terminate the transform, you could log
> the error and return some non-displayed helpful element (such as
> <error reason='blah'/>), or you could use a schema-aware transform and
> create a custom type for the $foobar value (which would also cause the
> transform to fail)
>
> Ultimately you might be better off restructuring the calling code, as
> that may be able to call the right method itself.


--
Matthieu Ricaud
IGS-CP
Service Livre numirique