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

Hello,

On the topic of "Bug 1824: Functions return xs:NCName, but xs:NCName is not 
support in XSLT 2.0 Basic"[1]:

Like a clever rabbit Michael's solution manages to sneak around that xs:NCName 
isn't supported by a Basic XSL-T processor. Even though the type isn't 
supported, the processor can derive what it do support. The controversial 
part according to me is that the resulting value isn't what the spec claim it 
to be(the result value isn't of type xs:NCName, but xs:string).

/If/ the user was able to execute for example "prefix-from-QName(QName()) 
instance of xs:NCName" Michael's solution wouldn't work. Therefore, it have 
that as assumption: the user cannot determine whether the resulting value is 
an instance of xs:NCName, the type it claims to be.

Can that assumption be broken elsewhere?

Implementations are allowed to store the typed value or the string value or 
both, as node values. What is the result if a basic processor produces a 
result tree which has typed values stored where one of the instances are the 
result(as abstract as it is phrased) of a xs:NCName function, and that a 
Schema aware processor afterwards processes this result tree? Here it can be 
seen that the value is not an instance of xs:NCName, but xs:string, and 
therefore produce different result depending on if the first transformation 
was done by a Basic or Schema Aware processor.

My idea sounds to me as an academic game. Does the problem I see  
theoretically exist at all, and if so, what impact does it have in practice? 
(Perhaps it needs WG consideration, I don't know.)

Apart from this speculative problem, I, as user and implementor, like the 
current solution.


Cheers,

		Frans

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

Received on Thursday, 29 September 2005 22:57:06 UTC