Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What are the characteristics of a good type system for XML
 Amy et al., This discussion on pluggable type libraries is very interesting and it's comforting to see that it fits in with the discussions some of us had about types in XPath NG a while ago. Just some random thoughts: I agree with Dare that thinking about how to define the processing of values of these pluggable types as well as their validation is really important. In particular, that means supporting casting rules and arithmetic operators as well as comparisons between values. John brought up the issue of types that don't have total ordering. The lack of total ordering of durations and date/times with or without timezones has been a real pain in XPath 2.0 because for optimisation purposes you really need just one of $a = $b or $a != $b to be true. You could, of course, introduce three-valued logic to cope with the ambiguity, but I'd be interested if anyone had any other bright ideas. Another area that I think would benefit from some consideration is the handling of compound types such as date/times (made up of year, month, day, hour, minute, second, timezone), durations (made up of years, months, days, hours, minutes, seconds) and QNames (made up of a local name and a namespace URI, plus a prefix depending on how you define it). These compound types are the cause of the proliferation of functions in XPath 2.0 like get-year-from-dateTime() and get-local-name-from-QName(). If we had a standard way of defining the components of a particular type, we could have a standard way of accessing them (such as an extract() function or a . operator). Finally, I think that there should be limits on the scope of a type definition. XML types like ID and ENTITY have too wide a scope, in my opinion, in that they specify constraints across entire documents as well as on particular lexical representations. A good rule would be that all you should need to tell whether a value is a legal value is the lexical representation itself, but unfortunately QNames wouldn't be allowed if that were the rule. Perhaps limiting the information available to the lexical representation plus XML-defined context information -- namely namespaces, the base URI, language and whitespace preservation -- would be better? 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
|
|||||||||
