[Bug 1824] Functions return xs:NCName, but xs:NCName is not support in XSLT 2.0 Basic

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1824





------- Additional Comments From frans.englich@telia.com  2005-09-07 13:10 -------
     
(I jump in with humble opinions and questions about Michael's proposed     
solution.)     
     
While Michael's solution may "ensure that the returned NCName can be used as a    
string"(I can't comment on that), I think there's another problem, that the  
type annotation is different, simply. From what I can tell, the proposed  
solution would result in that code introspecting the type annotation of the 
return value -- such as in a filter expression -- would behave differently 
depending on if it was executed on a basic of schema-aware 
implementation(unless the code catered for it). I think my point is 
theoretically correct, but I'm not sure how large the impact is in practice, it 
cannot occur at all perhaps(one cannot specify xs:NCName in basic).  
  
An in my opinion important aspect with XPath 2.0 is that there's a type system,  
and that means one can rely on that and deal with "types". However, to me it  
looks like the proposed solution makes an exception to this, that even though  
the function signature in F&O says "this function returns type Foo" it  
"sometimes" does not hold true. 
  
I find it natural that this dilemma occur. XSL-T Basic requires F&O, F&O  
requires xs:NCName, but XSL-T Basic does not have xs:NCName. When not using a  
solution similar to Michael's, two alternatives exists: removing/changing the  
functions that requires xs:NCName, or to add the type(s) to XSL-T Basic.  
Assuming the latter is ruled out, how does the discussion concerning the former  
sound? What are the disadvantages of changing the return type to xs:string?  
Why(if) is it not an option, and how does it compare to the proposed solution?  
  
The problem I see with the proposed solution is that it adds complexity and  
exceptions. Hence, I would find it interesting to look at a solution that is  
built upon the existing mechanisms.  
  
(A loose thought that springs to mind is to somehow allow basic processor to  
support derived primitive types, but it introduces well-known problems and also  
introduces what I identify as a problem.)  
  
  
Cheers,  
Frans

Received on Wednesday, 7 September 2005 13:10:14 UTC