fn:is-collation-available

[dnovatchev]

The new function fn:collation raises an error [err:FOCH0002] in the case when the requested collation is not supported. Or, if the fallback key's value is true(), then the implementation chooses "the most similar supported collation" - which could be perceived as arbitrary and unexpected by the code developer.

This might be OK if the language has try/catch capabilities and fallback="no" is specified, but may not be the best outcome in a pure XPath evaluation.

A solution to this problem is to provide a function fn:is-collation-available that accepts the same argument ($options map) as fn:collation, and also could accept a string argument whose value is the URI of the collation. This function produces a boolean, true() meaning that the collation is available and can be constructed and used, false() - otherwise.

Signature

fn:is-collation-available( $descriptor as xs:string | map(*) ) as xs:boolean

[ChristianGruen]

I assume that $descriptor as xs:string would be the actual URI?

Given that we already have fn:doc-available and fn:unparsed-text-available, we could name it fn:collation-available.

[dnovatchev]

I assume that $descriptor as xs:string would be the actual URI?

Yes

Given that we already have fn:doc-available and fn:unparsed-text-available, we could name it fn:collation-available.

Yes

[michaelhkay]

I would suggest taking the collation URI as the argument; if they want to use the map form they can write

collation-available(collation({'lang':'fr'})

for example; and using the parameter name $collation.

[joewiz]

Sorry if this is off-topic, but I first misread the post as asking for fn:collection-available.

Since calls to fn:collection can also raise errors (see https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-collection), should it perhaps also have this pairing?

For reference, eXist has an implementation-specific xmldb:collection-available function: https://exist-db.org/exist/apps/fundocs/index.html?q=xmldb:collection-available.

[ChristianGruen]

I would suggest taking the collation URI as the argument; if they want to use the map form they can write

collation-available(collation({'lang':'fr'})

for example; and using the parameter name $collation.

Maybe fn:collation should then be simplified to never raise an error?

[dnovatchev]

I would suggest taking the collation URI as the argument; if they want to use the map form they can write

collation-available(collation({'lang':'fr'})

for example; and using the parameter name $collation.

@michaelhkay, if fn:collation can return whatever collation the implementor thinks is closest to the one requested, then calling again to see if this collation is available is ... meaningless - of course it is available as the implementor suggested it.

In the other possible case, when the call to fn:collation results in a raised error, then the developer simply cannot get the value false() - the whole goal of the proposed function is not to have to deal with these two cases but just to obtain information that they would happen if fn:collation was called.

Or maybe you meant something else?

[michaelhkay]

if fn:collation can return whatever collation the implementor thinks is closest to the one requested, then calling again to see if this collation is available is ... meaningless

Yes, indeed, if the collation specifies fallback=yes, then the collation URI is available in every implementation, and the collation-available() function will always return true. It only makes sense to use collation-available() when you don't want the implementation to choose a "best efforts" alternative, that is, when you specify fallback=no.

But now I see your point. We have said that collation({'lang':'fr', 'fallback':false()}) will fail if the UCA collation for French is not available, and if this expression is going to fail, then there is no point using it as an argument to collation-available.

We could of course change the rules so that the collation() function doesn't fail; that is, so that it always returns a URI, and the failure only occurs when this URI is used as a collation name.

[dnovatchev]

We could of course change the rules so that the collation() function doesn't fail; that is, so that it always returns a URI, and the failure only occurs when this URI is used as a collation name.

And this bad end is exactly what the proposed fn:collation-available is design to avoid.

One use case is when the developer has a list of possible collations - best, good, so-so - and the code checks for the availability of these collations in this order, and uses the first of the three collations that is available.

[michaelhkay]

Closed by virtue of PR #1262