[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Date/time class changes to handle extended date ranges
From:       Frans Englich <frans.englich () telia ! com>
Date:       2006-02-20 18:44:34
Message-ID: 200602201844.35021.frans.englich () telia ! com
[Download RAW message or body]

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, 
xs:decimal, xs:integer.

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 
fails me.

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 
is conformant).

Then there is types Qt doesn't have classes for: xs:duration, xs:qName and 
xs:NOTATION.

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 
discussing here.

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, 
one month).

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.


Cheers,

		Frans
[prev in list] [next in list] [prev in thread] [next in thread]