- From: Henry Story <henry.story@bblfish.net>
- Date: Sun, 20 Nov 2011 13:22:13 +0100
- To: Dominik Tomaszuk <ddooss@wp.pl>
- Cc: WebID Incubator Group WG <public-xg-webid@w3.org>
On 20 Nov 2011, at 12:28, Dominik Tomaszuk wrote: > 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] because those are not defined in the xsd spec? > >> >> >>>> - 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 xsd:string. but any rdf engine supports xsd:hexBinary . > > [1] http://tools.ietf.org/html/rfc4648 > > Domel Social Web Architect http://bblfish.net/
Received on Sunday, 20 November 2011 12:22:46 UTC