This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Both of the arguments to this function have a cardinality of exactly one, whereas the corresponding arguments to unparsed-text are optional. This means you cannot reliably pass a computed value to unparsed-text-available, as a processor might deduce during the static analysis phase that the only possible value is the empty sequence, and accordingly raise a type error. Since unparsed-text would succeed if the first argument is an empty sequence, then unparsed-text-available should return true given the same value. For the encoding, if this is the empty sequence, then I am unclear as to what the processor should do - it does not seem to be specified - I'm personally treating it the same as if only one argument is present, but I think that legalistically the current spec. requires the processor to raise XTDE1190. In any case, unparsed-text-available should not suffer a type error.
The Working Group discussed this and agreed it ought to be fixed, and asked the editor to propose the detailed revision. Subject to confirmation by the WG, I propose the following. (a) to align with doc-available(), the first argument of unparsed-text-available() will accept an empty sequence, and will return false in this case. (b) we normally adopt a principle that where a value is optional, then it ought to be possible to specify an explicit value whose effect is equivalent to defaulting it. Applying this principle, I propose that if the second argumnent of unparsed-text-available() is an empty sequence, the effect should be the same as calling the one-argument version of the function. [There are counter-examples. We don't allow an empty sequence as the third argument of substring(), for example. However, it's not a big issue either way, and this seems a reasonable approach.] Michael Kay
Your proposed alignment with doc-available (empty sequence returns false()), will only be a true alignment if the wording for unparsed-text-available is change to read: "The unparsed-text-available function determines whether a call on the unparsed-text function with identical arguments would return a non-empty string" (then it aligns with returning a document-node). But an empty string could be a sucessful fetch of a file - a zero-length text file, so i still think it should return true(). And after all, what is the point of the function? Surely, it is to avoid raising an error, so it should only return false() if an error would have occured.
Oops! It DOESN'T return a string in that case. So false() is appropriate, and I suggest wording of: "The unparsed-text-available function determines whether a call on the unparsed-text function with identical arguments would return a non-empty sequence"
I can see your point. But I don't see where you get "non-empty string" from. We should change it from: The unparsed-text-available function determines whether a call on the unparsed-text function with identical arguments would succeed. to The unparsed-text-available function determines whether a call on the unparsed-text function with identical arguments would return a string. which is an exact analogy of doc-available(), which says: If fn:doc($uri) returns a document node, this function returns true Michael Kay
The XSL WG agreed with my amended proposal, which now is in three parts: (a) to align with doc-available(), the first argument of unparsed-text-available() will accept an empty sequence, and will return false in this case. (b) we normally adopt a principle that where a value is optional, then it ought to be possible to specify an explicit value whose effect is equivalent to defaulting it. Applying this principle, I propose that if the second argumnent of unparsed-text-available() is an empty sequence, the effect should be the same as calling the one-argument version of the function. [There are counter-examples. We don't allow an empty sequence as the third argument of substring(), for example. However, it's not a big issue either way, and this seems a reasonable approach.] (c) change the summary of the function to read: The unparsed-text-available function determines whether a call on the unparsed-text function with identical arguments would return a string. We are therefore marking the issue as FIXED/CLOSED. If you have any problems with this resolution, please reopen the bug. Michael Kay for the XSL Working Group