W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

Re: WebID ISSUE 61 (xsd): xsd datatypes [ontologies]

From: Dominik Tomaszuk <ddooss@wp.pl>
Date: Sun, 20 Nov 2011 12:28:11 +0100
Message-ID: <4EC8E44B.5060306@wp.pl>
To: Henry Story <henry.story@bblfish.net>
CC: WebID Incubator Group WG <public-xg-webid@w3.org>
On 20.11.2011 10:28, Henry Story wrote:
> On 19 Nov 2011, at 22:33, Dominik Tomaszuk wrote:
>> On 16.11.2011 17:19, WebID Incubator Group Issue Tracker wrote:
>>>   - xsd:base64Binary
>> -1 This datatype allows to incorrect values. For example:
>> rsa:modulus "XX YY ZZ"^^xsd:base64Binary;
>> Formally it is correct, but it isn''t hex value.
> xsd:base64Binary is for base64 encoded data. You don't encode it as above, and it was never suggested here that you should. Just look at the examples on the  issue page http://www.w3.org/2005/Incubator/webid/track/issues/61
OK, but also -1, because xsd:base64Binary add additional layer - 
encode/decode with base64 algorithm. Moreover there is a question why 
Base64 and why not Base 32 or Base 16? [1]

>>>   - xsd:hexBinary
>> +1
>> But I propose more readable and full-validate datatype based on xsd:string and restrictions to hex and "-" sign
>> (...)
> And what does that bring you? Now you can't implement type inferencing easily in your rdf engine. With cert:hex or xsd:integer you
> can have the rdf engine automatically convert any way of representing a cert:hex string into a BigInteger, and do immediate comparison using an ASK query.   With strings you would have to do a lot more messing around in code.
But this proposal is string datatype based. If RDF inference engine 
doesn't support regexp and OWL restriction - no problem it should use 

[1] http://tools.ietf.org/html/rfc4648

Received on Sunday, 20 November 2011 11:28:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:48 UTC