On Montag, 17. August 2009, Temlakos wrote: > Markus (and everyone): > > In SMW 1.4.2 and later, does any regular script even /use/ getXSDValue() > or parseXSDValue($value,$unit)?
I hope not. The API of those proved to be too inflexible, and was replaced by getDBkeys and parseDBkeys. The XSD-versions are kept for downwards compatibility since some extensions may still use them, but they will vanish at some point. > > The DBkeys scheme would seem to permit the passage of literally any > number of arguments. If that is the case, then I can solve the "slippage > problem" of imprecise dates. All I need to is to include the Julian Day > number in the return value of DBkeys. Hence, > > return array($this->m_xsdvalue,$this->m_pref,$this->m_jd); > > In that manner I can pass the exact same internal numeric value, and > eliminate the date-slippage problem. > > This will have to await the installation of later versions of SMW. Right > now I have a lot of obsolete dates to rewrite and reannotate, so that > they will have a proper test. > > Again, if I'm missing anything, please tell me. Changing the array returned by getDBkeys is only the first step, and in general one should be very careful changing the format of that array for an established datatype. Adding a value should not be a big problem though. However, the database engine currently does not store the arrays in a generic way but interprets them individually for each datatype. In particular, changing the array will not change the DB contents, since the store still assumes the old interface. Changing the DB contents of course always has a drawback that people will have to refresh their whole DB after updating SMW. But the main questions really is: what do you want to store in the 255 character string DB field that you have available for storing one date? The data format we use is not constrained in any way, since it will never be accessed by anybody directly. The main design criterion is that it should be possible to process it with minimal effort, with only very simple parsing and no complex calculations. Backwards compatibility of the DB can always be achieved later on by special code that checks if the old or new format was used (e.g. by starting all new format entries with some special character to distinguish them quickly). The current internal format lists all components of the date individually in an ISO-like way: YYYY-MM-DD ... but unspecified components are left empty. A simple string-split operation gives us all the components without any calculation. It would be possible to extend this format to also store (default) calendar mode and (default) timezone, but I think that it might be easier to keep all components as explicit strings instead of storing just one (Julian day) number from which actual dates need to be re-computed after reading the DB. -- Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
