-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
On 2009-03-05 20:15, Markus Krötzsch wrote: >> There is one thing I'm not 100% sure about though: Your implementation >> always prints out a complete date, like '2009-03-05' by printing out a >> default of '01' for the MM and DD parts when they are undefined. >> >> The Wikipedia article describing ISO8601, section "General principles" [2] >> says: "For reduced accuracy, any number of values may be dropped from any >> of the date and time representations, but in the order from the least to >> the most significant." >> >> So it would be possible to just omit the '-DD' or '-MM-DD' part when they >> are undefined. I would prefer this over SMW implying that the date is "on >> January the 1st" even though the precise point in time may actually be >> unknown. What do you think? > > I also read that article :-) I decided against using partial dates because I > assumed that it would complicate the life of people who use parser functions > to post-process the dates (I think this is the main application of using ISO > right now). Also, the old behaviour was to complete the date, so it recovers > the kind of downwards compatibility that was asked for. Hm... but do you really think it's the right thing™ to let SMW invent a part of the date even though that missing part may have been omitted deliberately? As it is now, whenever you see "YYYY-01-01" you have to wonder: is it really January 1st or did SMW make that up? I just don't feel very comfortable with that. > One could introduce more strings than "ISO" to have more fine-grained > formatting options. But this gets us into the hell of date formatting (there > are far too many options there) and of localization (man common formatting > directives for dates are heavily biased towards English). To be honest, I think we NEED to get into the "hell of date formatting". SMW is nice and all, enabling us to store and query - but what does it help when we can't get the stuff in exactly the way we need it out again? Maybe we could extend the SRF extension and add all the date formatters there? Another approach would be to let the *user* specify the output template (like it was in some older SMW version, where strftime date formatting strings were accepted, or based on MediaWiki's template "language" with a few well-documented magic words that return the date parts, like "__SMWYEAR4D__"...). I know there were problems because of a limited date range with strftime, but for some (maybe many) users those problems are actually more acceptable than just not having any options when it comes to formatting dates. I think this is really important - finding out that you can't get your queries to return exactly what you want is a huge show-stopper for people trying to *really* make use of SMW (more than just some proof of concept). Patrick. - -- Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmwyEgACgkQyYHmhobjRtR4GACfdPYlcxCLTVDQlMGz1xlg5G6y MO0An0AcCy3qKj1yVBRRZmXNbjK2jmnO =3srF -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
