- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sun, 11 Aug 2002 17:27:45 +0100
- To: xmlschema-dev@w3.org, "Michael Rossi" <mrossi@csc.com>
Hi Michael, > BTW - I did notice that there's a hexBinary type already in the > spec. My hesitation in using it was that it (obviously) implies a > hex encoding of binary data. I'm simply dealing with Hex data > (although it always comes down to binary at some point, of course > :-). Are there any processing implications of using hexBinary to be > concerned about? TIA. As I understand it, an application will internally store the value of an xs:hexBinary node as the bytes that the hex encoding signifies, so obviously the storage requirements will be a lot less than it storing the characters representing the hex encoding of that stream (especially when you consider that the internal character encoding of the application is likely to be UTF-16, using 2 bytes for each character, so each actual byte ends up being represented internally in 4 bytes). If you're only using small sets of data, that probably doesn't matter, though. I'm not clear why you don't want to use xs:hexBinary as the data type for your node. It would provide you with your regexp checking for free, and it sounds as though it's more accurate to say that the value *is* hex rather than that it *is* a sequence of characters. The equivalent of: <xs:simpleType name="8bytes"> <xs:restriction base="xs:token"> <xs:pattern value="[0-9a-fA-F]{16}" /> </xs:restriction> </xs:simpleType> is: <xs:simpleType name="8bytes"> <xs:restriction base="xs:hexBinary"> <xs:length value="8" /> </xs:restriction> </xs:simpleType> if you want to change it. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Sunday, 11 August 2002 12:27:47 UTC