Date/time class changes to handle extended date ranges
R.F. Pels
ruurd at tiscali.nl
Mon Feb 20 21:58:00 GMT 2006
On Monday 20 February 2006 19.44, Frans Englich wrote:
>> 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.
These do not necessarily have to be added to QDate, correct? I mean, this
could also be part of a connector of some sorts? OTOH, it would be a shame
not to make use of datestring parsing already contained in QDate. Hmmm. A
QDate /does/ already know how to parse date strings, so adding parsing for
xs:date actually does not violate the mandate of QDate.
> QByteArray would have a fromString() function parsing xs:hexBinary and
<huge snip/>
> 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.
That indeed depends on wether Qt has a demand for it.
> 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.
<nods/> Yes, I agree. Sounds like a plan.
--
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel
mailing list