Date/time class changes to handle extended date ranges
frans.englich at telia.com
Mon Feb 20 18:44:34 GMT 2006
On Monday 20 February 2006 15:10, R.F. Pels wrote:
> On Monday 20 February 2006 15.27, Frans Englich wrote:
> >> Those are good points. Mind you, the specification of WXS DateTime
> >> includes a flag indicating wether it is timezoned.
> Frans: now that we landed on that subject, are there any other hiccups with
> respect to implementing WXS Part 2 datatypes other than
> QDate/QTime/QDateTime which could be tackled?
If you want to deal with WXS types via Qt-only you have to add code; how much,
depends on what you want to do. Let's say, that "given a string I want to
manually create an instance of the value," then I'd say this is needed:
Extend Qt to accept lexical representations of the types. For example, 1) to
Qt::DateFormat would be added something like XSDate; 2) QDate would have a
'static QDate fromString(const QString &lex, const Qt::DateFormat format,
bool *ok)' which creates a QDate from a lexical representation of xs:date,
setting @p ok to false if @p lex doesn't validate.
QByteArray would have a fromString() function parsing xs:hexBinary and
xs:base64Binary; QString would handle xs:boolean, xs:double/float,
QUrl would have 'static QUrl fromAnyURI(const QString &lex, bool *ok)',
handling xs:anyURI(whitespace facet and slightly different escaping, IIRC). I
think I've mailed qt-bugs on doc-clarification on this long ago, my memory
The types xs:gYear, xs:gYearMonth, and the other xs:g*, can probably be
handled with QDate, although that's a bit excessive(but I think it works and
Then there is types Qt doesn't have classes for: xs:duration, xs:qName and
xs:duration is an /amount/ of time(for example, 2006 /years/, not this year).
One could create a "QDuration" class for that. There's also the types
xdt:dayTimeDuration and xdt:yearMonthDuration that will likely be in WXS 1.1
(I can keep people in the loop on that, if of interest) which essentially are
sub-classes of xs:duration.
One cannot create an xs:QName value from only a lexical representation, one
needs a context for resolving namespace prefixes. One could create a QQName
class that has "static QQName fromString(const QString &lex, const
QList<QPair<QString, QString> > &resolutionContext, bool *ok)" where the last
argument is a list of prefix/namespace pairs(or, one could create a
NamespaceResolver class, or use a typedef for the pair-list type).
xs:NOTATION is an abstract type. One can first use it by sub-classing it with
a user-defined type, so it's outside the scope of the kind of support we're
All classes would also have functions for retrieving the canonical lexical
representation of the value space(I could kill you ten times over with such
phrases). For example, the canonical lexical representation for the
xs:duration lexical representation "P1Y13M", is the string "P2Y1M"(two years,
Another question is what one should be able to do with the values once they
are created. For things like QDate, QTime, QByteArray the answers are obvious
but QDuration needs perhaps a closer look.
XPath 2.0/XQuery 1.0 defines operators for the types such that one can
actually do things with the values and they are quite practical. For example,
one can add a duration to a date(conceptually identical to QDate::addDays(),
QTime::addSecs(), etc), one can multiply a xs:duration with an integer(say,
xs:duration("P1Y2M") * xs:integer("3") becomes xs:duration("P3Y6M")). I can
provide a complete list of such operators. This is implemented in KDOM's
XQuery implementation, but it would greatly simplify and speedup if it was in
Qt, of course.
But this all depends on what demands Trolltech is pleasing. I speculate that
this basic "value" support is useful to many people, and it also makes sense
from a technical perspective to put it in Qt. It would to me make little
sense to let Qt acquire more heavy WXS support such as reading Schema files
or navigating a type hierarchy.
If Trolltech has an "XML demand" from customers, I would put basic WXS-values
support in Qt, and then let kdelibs be the alternative for heavy features.
XML stacks requires tons of code and it would be nice to have that developed
the open source way.. This is perhaps a viable solution since kdelibs will
relatively easy deploy on Windows/OS X.
More information about the kde-core-devel