RE: XSLT 2.0: Writing untyped stylesheets - how much is possible?

> As the WG likely is well aware there is a lot of disquiet and 
> concern in 
> parts of the XSLT community about the typing requirements of XSLT 2.0.

Yes, we are aware that not all users want to use the facilities, and that
not all implementors want to provide them, and we have tried to design a
conformance profile to meet this requirement.
> 
> If there is a clear statement available in the various 
> documents on how this 
> issue pans out I would appreciate it if someone can point me 
> to it (I haven't 
> had time yet to read the new WDs in their entirety). A 
> statement of that kind 
> is certainly something that I would envisage as being 
> usefully included in 
> official documents, possibly in the context of a Primer 
> document which I had 
> suggested a few months back.

My view on this is that we shouldn't add any more documents to the current
weighty set. There are other channels for this kind of information, such as
the session Jeni Tennison is presenting an XML Europe tomorrow morning.
> 
> Am I correct in assuming, for example, that a type-unaware 
> stylesheet author 
> cannot use the date and time functions?

No. A basic XSLT processor must support atomic values with all the built-in
simple types such as xs:date and xs:dateTime. If an untyped attribute node
(say) is passed to a function that expects an argument of a function where
an xs:date is expected, the system will automatically try to convert it to
an xs:date. If the user constructs a string containing a date (using
concat(), for example), the string can be passed to a function that expects
a date by casting it:

format-date(xs:date(concat(@year, '-', @month, '-' @day)), "[mn] [do], [y]")



 I assume that when 
> one of these 
> functions meets a string which happens to be the lexical 
> expression of a date 
> that it will be typed as xdt:untypedAtomic and the processor 
> will reject the 
> argument to the function since it is not of the specified 
> type for that 
> function's argument. Is that correct? Or (less likely, it 
> seems to me) will a 
> date time function work on lexical representations in the 
> absence of a 
> schema?

If the value is xdt:untypedAtomic, then a cast happens automatically when
required. Values of this type generally result from atomizing of nodes that
have not been validated by a schema processor.

If the value is a string, then the user can do the conversion explicitly.
String values generally result from string operations such as concat() and
substring() - and of course from string literals.

> 
> If my assumption is correct, then many of the new XPath 2.0 
> functions will be 
> unusable by stylesheet authors of the mindset mentioned 
> earlier. Or, in other 
> words, such stylesheet authors will be excluded from many 
> benefits of XSLT 2.0.

No, all the functions are available. The only facilities that won't be
available are those explicitly associated with schemas and complex types.
> 
> I guess that there is a de facto "loosely typed profile" for 
> XSLT 2.0. Is it 
> expressed anywhere? How narrow a subset is it? How practical 
> or useful a subset is it?

It is described in the "Conformance" section of the XSLT specification.
Obviously, we hope that we've got it right and that it is practical and
useful. It actually corresponds fairly closely to the subset of the spec
implemented in Saxon 7.5, so there is some opportunity for users to give us
practical feedback on whether it works.
> 
> In summary I see two communication issues:
> 
> 1. Communication to the existing XSLT community of which 
> parts of XSLT 2.0 
> will be usable without W3C XML Schema knowledge. Currently it 
> isn't clear.
> 
> 2. Communicating the *how* of making a successful transition 
> from XSLT 1.0 to 
> XSLT 2.0. A Primer-type document is needed to help bridge the 
> knowledge gap.
> 

I don't think that more official documents are the answer. The communication
will happen, perhaps slowly and sometimes painfully, through the usual
informal channels - including this forum where necessary.

Michael Kay

Received on Wednesday, 7 May 2003 18:30:55 UTC