Re: ANN: a portable data component -- length
In this case, if I wanted to convert the same price into pounds sterling, it's not in fact a straightforward fixed conversion rate, but will depend upon multiple factors - the date that the transaction took place, any conversion charges that may apply and so forth.
If this is in fact recording a transaction, and the conversion rate is not in fact discoverable (and that's perhaps the biggest issue here) the idea of incorporating the units into the instance makes sense - the transaction costs involved in discovering the equivalences are higher than the cost of carrying the data in the first place. To me that should be the bigger decision determinant when talking about replication of information - is the cost of replication less than the cost of computation when the data is re-referenced.
I've seen that recently on specific MarkLogic projects. Certain information was in fact derivable from other information, but the derivation costs were pretty dramatic and couldn't be indexable. In that particular case, it made more sense to derive the relevant values and store them with the calling data as a key, even though such a field meant that the dataset was not formally normalized.
Of course, what this means in practice is that there really is no best practice with regards to units and conversions; it depends upon your requirements as to whether you derive or replicate.
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org
On Sat, Apr 9, 2011 at 3:57 PM, John Cowan <firstname.lastname@example.org> wrote:
Amelia A Lewis scripsit:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format