- From: Mike Haarman <mhaarman@infinitecampus.org>
- Date: Thu, 15 May 2003 04:27:52 -0500
- To: "Kay, Michael" <Michael.Kay@softwareag.com>, <public-qt-comments@w3.org>
----- Original Message ----- From: "Kay, Michael" <Michael.Kay@softwareag.com> Michael, Thanks for your thoughtful reply. I recognize there has been rather more heat than light generated around this issue. That is both the reason I wrote and the reason I hesitated so long. > > 1) A range of XPath 2 functions display indeterminate > > behavior in the absence of PSVI type annotation. > > I don't know what you mean by this. Could you please elaborate? I think that > all the behavior is well-defined, except in a few quite particular cases > where we have chosen to make it implementation-defined (e.g. collating > sequences). In the current toolset, if I ask for substring($date, 4, 1) I get it whether it is junk or not. The stylesheet doesn't fail. I appreciate why many consider this a problem. I feel that it is a significant factor in XSL's success. My understanding is that if I ask for fn:get-year-from-dateTime($date), in the absence of type annotation, $date will have a type xdt:untypedAtomic and asking for a function whose type signature demands a xs:dateTime will cause the processor to coerce $date and fail if it can't. > I suspect that the biggest part of validation cost is the cost of compiling > the schema into a form that constitutes an executable validator. It should > be possible to do this once, in the same way as stylesheets are compiled > once and executed repeatedly. If the compiled schema and the compiled > stylesheet are combined, there is considerable potential for efficiencies. I > think it would be a mistake to assume that performance impact will be a > show-stopper, or even that the net effect of introducing schemas will be > negative. It depends very much on the application. Thanks for your insight. I suspected that I was not seeing the whole picture and you have confirmed that for me. > You haven't really explained enough about your application architecture for > me to comment. Where does XSLT fit in? The presentation tier is a two-stage transformation generating web views or printed reports. XSLT is also used to manage data conversion. > Converting the same data between three different representations - > relations, objects, and XML - looks like the inefficient part of your > process to me. But I can't really judge. Performance of our current application is quite solid and scales very well. I'd like not to introduce validation in the production system. > It's worth pointing out that the type information in the data model used as > input to an XSLT transformation does not necessarily have to come from > schema validation. Implementors might well provide utilities that create a So I have learned from Mr. Rys. If I could persuade you to comment on the clarification I made in reply to his message, I would be obliged. > Absolutely not. What gave you that impression? The mistaken notion that type annotation cannot be applied in the absence of schema validation. But I still hang here on the idea that the behavior of any given function, operator or instruction is dependent upon whether or not a type annotation is available for the datapoint. Doesn't this draw a much sharper distinction than currently exists between a valid instance and one merely well-formed? Doesn't this prevent me from simply throwing a switch for validation? My stylesheets must know whether to expect annotation or not. > I will refrain from speculation on this. Partly because I have no idea what > you mean by "userspace". The place where people who are not professional developers go to use a computer for anything other than email and surfing. I am a linguist by training, a poet by avocation and a self-taught developer. I fondly recall the stupid ease with which I began to use a computer for real work when XML arrived. I owe my current career to markup. Many pay lip service to the idea that XML gives control of data back to users; few appreciate how enabling and ennobling that experience can be. I would hate for that potential to be lost. > If you could make concrete suggestions as to how it could go further, that I cannot. And in light of the potential to annotate datatypes without validation, there is little that would further. > Clearly the languages are trying to meet a range of different needs. If you > think the design can be improved, without reducing the range of requirements > we are trying to satisfy, then we will welcome concrete suggestions. I do not. I guess I do feel that the range of requirements the WG is trying to satisfy is part of the problem. I recognize that train has left the station. > Please - if you think the behavior is "unsafe" then you must tell us how. I am not thinking of type safety per se. I am thinking of the lexical failure of an automatic cast performed by a *Basic XSLT Processor* as described in XSLT 2.0. Perhaps this is only an issue over the XSD built-in types and more of a molehill than it seems at first blush. > You > obviously have some particular problem in mind here, please tell us what it > is. That my stylesheets must be aware of whether or not they are dealing with annotated data. With many thanks for your cogent response, Mike
Received on Thursday, 15 May 2003 05:28:42 UTC