[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSLT 2.0 / XPath 2.0 - Assumptions
Jonathan Robie wrote: >>Are we talking about the XPath built-in types or the W3C XSD >>"primitive" types? My sense of the 80/20 point for typing is >>strings, date-time, integers, floating points ... maybe 1-2 more. >>The 30 or so "primitive" types that make controversial distinctions >>between short and long integers, dates and times, etc. etc. do not >>seem like a sensible starting point for a minimial conformance >>level. > > I can understand the desire for fewer types. But if you support any > data types in documents, its hard to justify not supporting those > data types found in the documents that are being queried, which may > belong to any built-in type. Yes, I'm not sure that you can draw the line at the primitive data types, in particular because that means you can't distinguish xs:ID or xs:integer, which seem to play a fairly major role in XPath/XQuery. (Although I don't see any particular reason why they should particularly -- XPath 1.0 managed OK with the equivalent of xs:double, and as I've argued previously, xs:ID isn't as useful as you might think.) >>What about the functions and operators? That seems at first glance >>like something that could be pared down significantly for a minimal >>implementation. I guess a lot of them would be irrelevant if only >>the built in types are supported.... > > You got that right. Or if we had a general framework for data > accessors that did not require a new function every time you want to > get one field out of a simple type like a date. I think that's certainly worth considering. I was toying with the idea of "virtual elements" of some kind, so that a date could be manipulated as if it were in the format: <year>2002</year>-<month>05</month>-<day>13</day> such that if you had: <date xsi:type="xs:date">2002-05-13</date> you could get the year of the date using: data(date)/year I suspect that's overloading the / operator, however. Perhaps just a "of" operator would be useful: year of date (QName "of" Expr) being the equivalent of the current: get-year-from-date(date) I think that the question to be answered here is whether XPath 2.0 should support external objects. If the answer is "no", then I don't think it should be too much of a burden to list (or supply general rules for) the functions that extract specific data from atomic values of the 19 primitive types -- at least it is a finite list. If, on the other hand, XPath 2.0 is going to support external objects, then a general mechanism for accessing the properties, and possibly methods, of those objects would be useful. I am vaguely in favour of supporting external objects, since it gives the room for extension and customisation that I think is important in a core technology like XPath. If, for example, XQuery decided that it wanted to pass around "type definition" objects, then these could be treated like other external objects within XPath. Similarly, if a future version of XSLT wanted to extend XPath to support functions as objects, then it could do so. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|