W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: md5sum and sha1sum functions

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 7 Dec 2010 10:43:59 +0000
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <E88B6734-D77F-43B2-A5DB-87ABC77F07A6@garlik.com>
To: Paul Gearon <gearon@ieee.org>
On 2010-12-06, at 17:39, Paul Gearon wrote:

> On Mon, Dec 6, 2010 at 7:44 AM, Steve Harris <steve.harris@garlik.com> wrote:
>> If these are going to return a simple literal containing hex characters, rather than some 128 / 160 / 256 bit integer datatype, then I'd prefer MD5_HEX() etc.
> The standard result of this algorithm is almost always presented as a
> hex string, so that may be redundant. It might be nice to have a
> version that returned a xsd:hexBinary. I also thought it would be nice
> to accept an xsd:hexBinary as an alternative to a string. That said, I
> didn't suggest anything like these since I was trying to keep it
> simple, and not bloat the spec.

OK, the languages I'm most familiar with (C and Perl), return big integers (actually structs of ints) by default.

I guess I don't foresee any serious problems just returning hex strings in SPARQL.

>> I marginally prefer named functions, e.g. SHA256_HEX(?x), rather than SHA_HEX(?x, 256). Length might not be enough to distinguish all algorithms on it own, so we could end up with some odd cases.
>> BTW, hexadecimal SHA1 values are 40 characters long.
> They are indeed. I copied/pasted from MD5 and missed that part, sorry.

I guessed that was the problem, the intent was clear enough.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 7 December 2010 10:44:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:02 UTC