[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

xml characteristics
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?



Jeni Tennison


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.